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EXAMPLES  OF  PREDICATIVE  SPECIFICATION'S 


SMALLER  EXAMPLES 

The  specification  of  a  data  transformer  generally  consists  of  two  predicates.  One 
describes  the  output  independently  of  the  input:  the  other  relates  the  output  to  the  input. 
For  example,  to  specify  sorting,  we  have  to  indicate  both  that  the  output  is  in  fact  sorted, 
and  that  the  output  is  a  permutation  of  the  input: 

Input:  X[l..n]: 

Output:  X'[l..n]; 

Allop  (A :  {X’[i]  <  X  *[»  +l]  I  1  ^  i  <  ill): 
permulationiX ,  X' ). 

Notation:  for  any  associative  and  commutative  operator  op.  Allopiop;  set )  indicates  a  distri¬ 
butive  application  of  the  operator  over  set.  For  example,  if  S  =  |5.  12.  14}.  then  Allopi- K  S') 
=  5+12+14  =  31.  The  expression  in  A  given  above  is  equivalent  to  Vi:  1  ^  i  <n: 
X'[i  ]^X'[i  +l].  Often  the  set  is  defined  by  the  use  of  a  defining  predicate:  {r  I  Pis  )).  read 
as  "the  set  of  all  elements  s  such  that  the  predicate  P  is  true  for  5.”  In  our  example  the  set 
consists  of  all  statements  X '[i  ]  ^  X‘[i+l]  such  that  1  ^  i  <n.  Note  that  AllopiV : 
nullset)  =  false  and  that  Allopi A;  nullset)  =  true. 

Suppose  that  we  wanted  a  function  that  returned  the  quotient  q  and  remainder  r  of 
the  division  of  the  nonnegative  integer  x  by  the  positive  integer  y.  Here  the  two  com¬ 
ponents  of  the  output  are  related  to  the  input  by  the  expression 

ix-yXq+r)  A  (0  <  r  <  y  ). 

Similarly  we  can  specify  a  function  that  inverts  a  matrix  A  by  relating  its  output  B  to  A 
and  to  the  identity  matrix  /:  AB  =  I. 


Another  simple  specification  is  that  of  the  greatest  common  divisor.  Here  we  define 


divides  (i :  Cardinal  ;  x  :  Natural )  =  Allop  (V:  {i  X  q  =  a:  I  Q^q  }): 

gcd  ( g  :  Cardinal ;  x  ,  >■ :  Natural  )  =  divides  (g  .  x  )  A  divides  (g  .  y  ) 

A  not  (Allop  (V .  { divides  (i  .  x  )  A  divides  (t  .  v  )  I  g  <i  ^ min  (.v  ,  y  )})). 

A  function  can  be  defined  in  terms  of  gcd: 

fgcd  (x  .  v  :  Natural  )  =  getelement  ({g  I  gcd  C g  .  x  ,  y  ))J. 

where  getelement  is  a  function  that  extracts  an  element  from  a  set  (here  the  set  consists  of  a 
single  element,  namely  the  greatest  common  divisor  of  x  and  y). 

Instead  of  defining  gcd  in  terms  of  divides,  we  can  specify  it  by  means  of  three 
axioms: 

gcd  (x  .  x  .  0); 

gcd(g  .x  .y)  =  gcd  (g  ,x+y  .y  ): 
gcd  (g  .  x  .  y  )  =  gcd  (g  ,  y  .  x  ). 

In  mathematical  language,  we  have  here  a  theory  of  the  greatest  common  divisor,  from 
these  axioms,  together  with  the  relation 

x  =  y  X  div  (a-  .  y  )  +  rem  (a  .  y  ). 

can  derive  the  predicative  specification 

y  >  0  — >  gcd  (g  .  x  ,  y)  =  gcd  (g  .  y  .  rem  (a  ,  y  ))). 

which  can  serve  as  a  basis  for  an  implementation  of  the  gcd  function. 

A  TEXT  FORMATTER 

The  text  formatter  is  one  of  the  problems  selected  for  study  at  the  Fourth  Interna¬ 
tional  Workshop  on  Software  Specification  and  Design.  Here  the  input  is  a  string  over  the 
alphabet  CH.  and  this  string  is  to  be  split  into  lines.  The  input  consists  of  words  separated 
by  sequences  of  break  characters .  namely  sequences  of  blanks  (BK)  and  linefeeds  (LF).  Let 
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BC  =  (Bk.  LF}.  Then  a  word  is  a  sequence  of  characters  from  SC  =  CH  -  BC  such  that  the 
character  to  the  left  of  this  sequence  (if  any)  and  the  character  to  the  right  of  the  sequence 
(if  any)  belong  to  BC.  The  first  word  of  the  input  may  be  preceded  by  characters  from  BC, 
and  characters  from  BC  may  follow  the  last  word  of  the  input. 

The  output  is  to  contain  precisely  the  words  of  the  input  in  precisely  the  order  that 
they  have  in  the  input.  The  length  of  an  output  line  is  not  to  exceed  the  value  nui a/au.  11 
the  input  contains  a  word  that  consists  of  more  than  maxpos  characters,  then  the  entire  out¬ 
put  is  to  be  just  the  one  single  character  BK.  The  first  word  of  the  output  is  not  to  be  pre¬ 
ceded  by  any  characters  from  BC,  and  the  last  word  is  not  to  be  followed  by  any  such  char¬ 
acters.  The  objective  is  to  minimize  the  number  of  output  lines.  This  objective  is  achieved 
if  the  output  lines  are  built  up  in  the  order  they  have  in  the  output,  and  for  every  line  an 
attempt  is  made  to  pack  as  much  of  the  remaining  input  into  this  line  as  the  line  can  take. 
However,  a  specification  is  not  to  show  bias  toward  a  particular  implementation.  Therefore 
the  description  of  the  output  will  be  totally  declarative.  This  is  particularly  important 
here  because  the  number  of  significantly  different  reasonable  implementations  is  quite  large. 

We  denote  a  string  by  S(l)S(2)....S(A0,  where  length(S )  =  N.  Then  let  the  input  string 
be  B(l)B(2)...B(length(B)),  and  the  output  string  C(l)C(2)...C(length(C)).  There  are  two 
parts  to  the  specification.  The  first  part  consists  of  predicates  that  we  consider  of 
sufficiently  general  interest  to  be  part  of  the  data  type  of  strings  of  words.  The  other  part 
consists  of  predicates  specific  to  this  application. 

Three  of  our  predicates  belong  to  the  data  type  of  strings  of  words:  word(S,  i,  j)  is 
true  if  the  character  sequence  S(i)...S(y)  defines  a  word:  word~number(S,  k,  i,  j )  is  true  if 
S(i)...S(j )  defines  the  £th  word  of  S',  word~count(S,  k )  is  true  if  S  contains  k  words. 

word  ( S  :  String  :  i ,  j  :  1.. length  (S  ))  = 
i  ^  j 

A  (t  ^  1 )  — >  member  (5  (i  —1 ).  BC  ) 

A  (y  length  (S  ))  — *  member  (5  (y  + 1 ).  BC  ) 

A  Allop  (A ;  ! member  (5  {k).  SC  )  I  i  ^ k  ^  j  }); 


4 


word  number  (5  :  Siring  :  k  .  i  .  j  :  Cardinal  )  = 
word  (5  .  i  .  j) 

A  {k  =  1 )  — *  Allop  (A ;  {member  (S  (t  ).  BC  )  I  1  <i  I ' 

A  (k  >  1 )  — *  Allop  (V  ;  I  word  number  (S  .  k  —  1 ,  u  .  v  )  A 

Allop  (A ;  j  member  (S  ( t  ),  BC  )  i  <r  <i  b 
i  member  {u  ,  Cardinal  )  A  member  (v  .  Cardinal  )} }: 

word  'count  (5  :  Siring  :  k  :  Cardinal )  = 

(A:  =  0)  — *  AUopiA',  {member  (Sit  ),  BC  )  I  1  ^length  (S  )}) 

A  (k  >  0)  — *  Allop  (V ;  {word  ~ number  (S  .  k  .  u  ,  v  )  A 

Allop{/\\  {memberiSU  ).  BC  )  !  v  <i  ^ length  (5  )}) 

I  member  {u  ,  Cardinal  )  A  member  ( v  ,  Cardinal  )) ): 

Let  us  examine  the  predicate  word  in  some  detail.  The  four  conjuncts  in  its  definition 
establish,  respectively,  that  limits  i  and  j  are  properly  related,  that  S(i)...S(j)  either  starts 
at  the  left  boundary  of  S  or  has  a  break  character  preceding  it.  that  S(i)...S(j)  either  ends  at 
the  right  boundary  of  5  or  has  a  break  character  following  it.  and  that  no  characters  in 
S(i)...S(j)  are  break  characters.  In  the  definition  of  word' number  the  first  conjunct  identifies 
the  character  sequence  defined  by  i  and  j  as  a  word.  Then  it  is  asserted  that  all  characters 
preceding  the  first  word  are  break  characters.  The  sequence  number  of  subsequent  words  is 
established  recursively:  it  is  asserted  that  there  exist  character  positions  u  and  v  that  define 
word  k-\.  and  that  all  characters  between  the  end  of  this  word  and  word  k  are  break  char¬ 
acters.  The  interpretation  of  the  definition  of  word  count  is  left  as  an  exercise. 

The  next  set  of  predicates  relates  to  the  application.  Predicate  agrees  matches  up  the 
output  words  with  the  input  words,  and  predicate  special  case  determines  whether  or  not 
the  input  contains  any  word  that  is  too  long.  Predicates  breaks' ok  and  lines'ok  relate  to  the 
output:  break  s' ok  establishes  that  there  are  no  leading  or  trailing  break  characters,  and  that 
there  is  precisely  one  break  character  between  each  pair  of  words;  lines  ok  establishes  the 
proper  placement  of  linefeeds. 
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agrees  (B  .  C  :  String  )  = 

Allop  (V  ;  1 word  count  (B  .  k  )  A  word  count  {C  ,  k)  A 
,4ZZo/>  (A ;  { 

AllopiM  :  {word  number  {B  ,  f  .  i  ,  j  )  A  word  'number  (C  .  t  .  u  .  v  )  A 
j  —i  =  v  —u  A 

Allop  (A:  {B  (i +q  )  =  C  (u +q  )  I  O^q^y—i}) 

I  subset  ({i  .  j  .  u  .  v  \ .  Cardinal  )}) 

I  l<r  }) 

I  member  (£  ,  Cardinal )}); 

breaks  ~ok  (C  :  String  )  = 

not  {member  (C  ( 1 ),  BC  )) 

A  not(memZ>er  (C  ( length  fC  )),  BC  )) 

A  Allop  (A ;  {member  (C  (  j  ).  BC  )  — *  not  {member  (C  (  J  +1),  BC  )) 

I  1  ^  j  <length  (C  )}); 

lines  'ok  (C  :  String  )  = 

Allop  ( A ;  (C  (i  )^LF  I  1  <i  <length  (C  )} )  — *  length  (C  max pos 

A  Allop  (A :  |C  (i  )-LF  —> 

( length  (C  )— i  ^  max  pos  V  Allop  (V ;  {C  ( y  )=A/r  I  t  <  /  ^ maxpos  -hi  +l)))  A 
Allop  (V ;  {word  (C  .  i  +1 .  k  )  A  i  <maxpos  — >  maxpos  A  j  >  maxpos  — » 
Allop  (V ;  {C  (g  )—LF  A  t  —  g  —1  ^ maxpos  A  k  —q  >  maxpos 
I  1  $ q  <i  }) 

1  i  <k  ^ length  (C  )} ) 

I  1  <i  <length  (C  )}): 

special  case  ( B  :  String  )  = 

Allop  (V  ;  {word  (B  ,  i  .  j  )  I  (l  ^i  .  j  ^ length  ( B  ))  A  j  —i  ^ maxpos  )); 

conversion  ok  (B  .  C  :  String  )  = 

special  'case  (B  )  — *  ( length  (C  )=1  A  C  ( 1  )=BK  ) 

A  not  (special  case  iB))  — *  ( agrees  (B  ,  C  )  A  breaks  ~ok  (C  )  A  lines  ~ok  (C  )): 

Predicate  agrees  asserts  that  strings  B  and  C  contain  the  same  number  of  words,  that 
corresponding  words  in  B  and  C  contain  the  same  number  of  characters,  and  that 
corresponding  characters  are  equal. 
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The  definition  of  lines'ok  is  the  most  difficult  to  interpret.  If  the  output  string  C  con¬ 
tains  no  linefeeds,  then  it  occupies  just  one  line,  and  UngthiC  >  ma\  no!  exceed  ma.xpos  If  C 
contains  more  than  one  line,  then  for  every  linefeed  in  C  ii  has  to  he  established  that  the 
end  of  the  string  or  another  linefeed  is  not  too  far  away  on  the  right  further,  if  this  is  the 
first  linefeed  in  C.  then  it  has  to  be  shown  that  the  length  of  the  substring  between  Ct  1 ) 
and  the  end  of  the  first  word  that  follows  the  linefeed  exceeds  -  other*  ise  the  length 

of  this  substring  is  measured  from  the  preceding  linefeed. 

The  specification  of  the  text  formatter  was  very  difficult  to  write,  and  it  is  difficult  to 
interpret.  Moreover,  one  has  to  be  careful  to  make  the  specification  complete.  For  example, 
the  assertion  j—i  =v  —  u  in  predicate  agrees  is  a  later  addition.  Without  it  the  strings  "This 
man  is  my  husband"  and  "This  maniac  is  my  husband"  would  be  found  to  agree. 

TWO-WAY  MERGE 

Consider  input  streams  of  records  defined  by  the  follow  ing  key  sequences. 

A:  5  7  3  12  57  32  17  19  27  18  43  15 
B:  2  911  8  15  30  42  20  35 

Runs  from  the  input  streams  are  merged  to  produce  output  runs.  Thus  (5.7)  and  (2.9.11) 
yield  (2.5.7.9.11):  (3.12.57)  and  (8.15.30  42)  yield  <  3.8.12.15.30.42.57):  (32)  and  (20.35) 
yield  (20.32.35).  The  merged  runs  go  alternately  into  output  streams  C  and  D.  At  this 
point  input  stream  R  has  been  exhausted,  but  three  runs  still  remain  in  stream  A.  The  first 
and  third  go  into  D  the  second  into  C.  The  output  streams  are 

C:  2  5  7  9  11  20  32  35  18  43 
D:  3  8  12  15  30  42  57  17  19  27  15 

The  two-way  merge  is  defined  in  terms  of  the  following  predicates. 
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run  (.4  ;  t  ;  j  )  =  Allop  (A :  i  A  [&  ]  ^  A  U  +l]  I  i  ^ k  <  j  }) 

A  i  >  j  — *  A  [t  ]  <  A  [:  —  lj 
A  j  <n  — *  A  [j  ]  <  A  [j  +1]: 

runnumber  (.4  .  k  .  i  .  j  )  =  run  {A  .  i .  j) 

A  k  =1  — *  i  =1 

A  k  >  1  — »  Allop  (V ;  { runnumber  (A  .  k  —1,  u  .  i  —1 )  !  l^u  <i  }); 

runcount  (A  .  k  )  =  (k  =0)  — *  null  {A)  A 

( k  >0)  — *  Allop  (A  ;  {runnumber  (A  .  k  ,u  ,  n  )  I  1  }): 

In  our  example  above,  there  should  be  three  runs  on  C.  However,  if  we  apply  predi¬ 
cate  runcount  to  C.  we  find  that  k  is  2.  i.e..  the  runs  (2.5,7,9.11)  and  (20.32,35)  have 
coalesced  into  a  single  run.  This  worsens  matters  to  the  extent  that  we  need  a  complicated 
separate  predicate  to  define  output  "runs". 

outrun  (D  .  k  ,  t  .  j  )  = 

noi(Allop  (V :  { runnumber  (A  .  k  X2.  u  ,  v  )  I  v  ^ size  U)Au  }))  — > 

Allup  (V ;  | runnumber  IB  ,  k  X2.  s  .  t  )  A  D  [i../  ]  =  B  [r..t  ]  I  t  $ size  (B  )  A  s  ^t  }) 

A  noiiAllop  (V  ;  {runnumber  [B  .  &  x2.  u  ,  v  )  I  v  ^size  (B  )  A  u  }))  — > 

.4/Zo/>  (V ;  jrunnumier  ( A  .  k  X2,  s  .  t  )  A  D  [i..j  ]  =  /l  [j..t  ]  I  t  ^size  (.A  )  A  s  ^t  }) 

A  Allop  (V :  |ru/mumZ>er  ( A  ,  k  x2.  u  ,  v  )  A  runnumber  ( B  ,  k  X2,  5  ,  t  ) 

l  v  ^ size  (A  )  A  u  A  t  ^ size  {B  )  A  s  J)  — > 

Allop  (V  :  i merge  ( D  [i..j  ].  A  [u..v  ].  B  [j..r  ]) 

I  v  ^ size  (A  )  A  u  A  t  ^ size  (B  )  A  s  }); 

outok  (D  .  k  )  =  Allop  (V  ;  { outrun  (D  .  k  ,  i  .  j  )  I  1  ^  i  .  j  ^size  ( D  )}): 

Analogous  definitions  can  be  written  for  C.  The  definition  of  predicate  merge  is  left  as 
an  exercise.  The  two-way  merge  itself  may  now  be  specified. 

two  way  ~ merge  {A  ,  B  .  C  .  D)  — 

Allop  (A ;  {outok  (C  ,  i  )  I  1  ^  i  ^  div  ( max  ( fruncount  {A  ),  fruncount  ( B  ))+l,  2)1) 

A  Allop  (A  ;  {outok  (D  .  i  )  I  1  ^  i  ^  div  ( max  ( fruncount  (.A  ),  fruncount  ( B  )),  2)}): 

where 
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fruncount  (.4  )  =  get  element  (U  I  runcount  (A  .  k  )} ): 


Sorting  by  the  two-way  merge  is  accomplished  by  applying  the  operation  specified  by 
predicate  rwo  way  merge  first  to  .4  and  B.  then  to  C  and  D.  then  to  A  and  B  again,  and  so 
forth  until  one  of  the  output  streams  is  empty.  However,  the  predicative  specification  is 
very  complicated,  and  it  may  be  worthwhile  to  try  a  different  approach. 

We  propose  a  generator  that  delivers  the  next  value  of  a  data  stream  each  time  it  is 
invoked,  and  further  propose  that  tags  be  associated  with  the  values  delivered  by  the  gen¬ 
erator.  There  are  to  be  three  tag  values:  N(ormal).  H(old).  and  F(inished).  The  tag  value  is 
H  after  the  generator  has  delivered  the  last  item  of  a  run.  unless  this  is  the  last  item  of  the 
entire  input  stream,  in  which  case  the  value  is  F.  Otherwise  the  value  is  N.  Let  us  now 
assume  that  the  generator  has  state.  Then  the  behavior  of  the  generator  can  be  described  in 
terms  of  state  transitions. 

N  Stay  in  state  X'.  or  change  to  H  or  F.  If  new  stale  is  X.  advance  to  next  item  in  input 
stream. 

H  Change  state  to  \,  advance  to  next  item  in  input  stream. 

F  Stay  in  state  F. 

The  permissible  state  transitions  are  shown  in  the  diagram  below.  The  node  representing 
state  \  is  doubly  circled  because  the  generator  starts  in  this  state  (unless  the  input  stream 
is  empty,  in  which  case  it  starts  in  state  F). 
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The  tag  values  make  it  easy  to  specify  a  program  that  accepts  data  from  the  two  input 
streams  and  moves  these  data  into  the  two  output  streams.  We  assume  that  the  input  from 
the  generator  over  .4  is  in  location  Aval,  and  the  input  from  the  generator  over  B  in  Bval 
Each  record  is  assumed  to  contain  a  field  key. 

Tag-action  table  for  a  two-way  merge 

AB  Action 

NN  If  Aval  <  Bval  then  output  Aval  and  call  generator  over  A,  else  output  Bval  and  call 
generator  over  B 

NH  Output  Aval  and  call  generator  over  A 
NF  Output  Aval  and  call  generator  over  A 
HN  Output  Bval  and  call  generator  over  B 
HH  Call  generator  over  A  and  B\  switch  output  streams 
HF  Call  generator  over  .4;  switch  output  streams 
FN  Output  Bval  and  call  generator  over  B 
FH  Call  generator  over  B:  sw  uch  output  streams 
FF  HALT 

The  main  point  is  that  the  definition  of  the  generator  and  the  tag-action  table  consti¬ 
tute  a  full  specification  of  the  two-way  merge.  The  specification  is  abstract  in  the  sense  that 
it  is  independent  of  the  nature  of  the  input  streams  (files,  linear  arrays,  instances  of  some 
other  structure).  Moreover,  the  specification  easily  generalizes  to  a  three-way  or  a  four¬ 
way  merge.  Only  the  table  that  specifies  the  merge  needs  to  be  changed  (to  one  with  27  or 
81  entries,  respectively).  This  table  translates  immediately  into  a  program  composed  of 
nested  case  statements. 
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THE  SF  ( SET-FL ACTION )  METHODOLOGY 


A  specification  methodologx  for  information-control  systems  should  have  a  sound 
theoretical  base,  and  it  should  be  c  onsistent  with  the  approaches  used  in  the  specification  of 
other  software  elements.  The  SF  methodology  has  both  these  properties.  It  is  based  on  sets 
and  functions,  which  are  well  understood  mathematical  concepts.  Further,  since  the  essence 
of  data  abstraction  in  general  is  that  data  types  are  defined  in  terms  of  sets  and  functions. 
SF  is  consistent  with  the  general  principles  of  data  abstraction.  Moreover,  because  an  SF 
data  type  and  the  events  associated  with  it  define  each  other,  the  specification  is  self- 
contained.  The  SF  methodology  has  been  used  to  write  the  specifications  of  quite  a  number 
of  software  systems,  among  others  the  1F1P  Working  Conference  example,  which  can  be 
regarded  as  a  standard  benchmark,  and  a  system  for  handling  bank  accounts.  Note,  how¬ 
ever.  that  the  1F1P  Working  Conference  example  was  written  while  SF  was  still  being 
developed,  and  has  the  serious  flaw  of  not  being  modularized. 

An  SF  specification  consists  of  one  or  more  segments.  Each  segment  has  three  com¬ 
ponents: 

•  a  schema  definition. 

•  specifications  of  events, 

•  a  responder  that  consists  of  transactions. 

The  schema  definition  identifies  a  set  as  being  the  primary  set  of  interest  for  the  seg¬ 
ment.  e.g..  a  set  of  bank  accounts  or  a  set  of  library  books  or  a  set  of  persons.  In  addition  to 
the  primary  set  there  may  be  secondary  sets,  which  for  the  most  part  merely  provide  a 
range  for  a  function.  For  example,  in  a  case  study  discussed  below,  library  books  are 
tagged  with  indicators  of  their  subject  matter.  These  indicators  are  defined  as  a  secondary 
set.  The  schema  definition  also  defines  a  set  of  functions  (finite  maps),  which,  for  the  most 
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part,  have  the  primary  set  of  interest  for  their  domain.  Examples  of  functions  for  bank 
accounts:  balance  in  an  account,  overdraft  limit,  transactions  for  ihe  current  month  (a  set¬ 
valued  function).  Some  functions  have  a  null  domain— they  represent  properties  that  per¬ 
tain  to  the  entire  segment.  Constant  functions  for  the  bank  accounts:  interest  rate,  number 
of  transactions  for  which  the  bank  does  not  charge,  the  charge  lor  each  excess  transaction. 

Some  functions  are  defined  junctions.  They  can  be  defined  in  terms  ol  ether  functions. 
For  example,  we  could  have  a  predicate  referees  such  that  refereesir,  p)  is  true  if  referee  r 
has  been  assigned  as  a  referee  to  paper  p.  Then  the  function  refs  of  paper,  which  is  to  map 
from  the  set  of  papers  to  the  power  set  of  the  set  of  referees,  i.e..  which  is  to  return  the  set 
of  the  referees  of  a  paper,  can  be  defined  in  terms  of  the  predicate  referees'. 

refs  of  paper  (x  )  =  {y  :  referees  (y  ,  x  )}; 

Functions  that  are  not  defined  are  called  basic  functions. 

The  specification  of  events  consists  of  preconditions  and  postconditions.  Preconditions 
determine  under  what  circumstances  an  event  may  take  place.  They  serve  as  a  check  on  the 
feasibility  of  input  values,  and  embody  consistency  criteria  for  the  data  base  of  the  infor¬ 
mation  system.  Postconditions  are  subdivided  into  setconditions.  mapconditions.  and 
sigeonditions.  Setconditions  and  mapconditions  indicate  the  changes  that  sets  and  maps 
undergo  in  consequence  of  an  event  taking  place.  Sigeonditions  send  signals  to  the 
responder  in  the  form  of  raised  flags. 

Our  example  of  an  event  assigns  a  referee  to  a  paper.  The  preconditions  lest  that  the 
argument  p  does  indeed  belong  to  the  set  of  submitted  papers  S.  and  that  ref  is  an  active 
referee.  The  prefix  R  indicates  that  active  has  been  defined  in  the  segment  whose  primary 
data  set  is  R  (i.e..  the  set  of  referees):  similarly  for  prefixes  CO  (conference  organization) 
and  P  (persons).  The  other  preconditions  test  that  the  number  of  papers  assigned  to  ref 
does  not  exceed  a  limit,  that  ref  does  not  belong  to  the  same  organization  as  any  of  the 
authors  of  p,  and  that  the  number  of  referees  for  the  paper  does  not  exceed  a  limit.  The 
mapeondition  adjusts  predicate  referees.  Primed  entities  refer  to  values  after  the  event. 
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such  as  the  primed  referees  here.  Note  very  carefully  that  postconditions  are  assertions 
rather  than  assignments.  The  operational  interpretation  of  a  postcondition:  the  minimal 
modification  of  the  data  base  that  makes  the  assertion  hold.  The  sigconditions  set  flags:  flag 
paper' to' ref  is  to  initiate  the  actual  sending  out  of  the  paper  to  the  referee,  flag  find  refs 
remains  on  as  long  as  the  limit  on  the  number  of  referees  has  not  been  reached  lor  this 
paper. 

EVENT  Assign  ref eree' to  pa per{ p ,  ref): 

PRECONDITION'S-  member  ( p.S ): 

R.  active  ( ref  ): 

ref  paper  ~ count  ( ref  )  <  CO  ref  paper  limit  ; 

Allop  {f\ :  \nol{P  affiliation  {ref  )-P.  affiliation  {x  ))  \ 
member  (x  .  authors  {p  ))}; 
card  {refs  "of  "paper  {p  ))  <  CO.  ref  number  ; 

MAPCOXDITIONS—  referees  '{p  .  ref  )  =  true: 

SIGCONDITIONS-  {paper  "to'ref  {p  .  ref  ))ON: 

card  {refs  "of  "paper  '{p  ))=CO  ref  "number 
— »  {find  refs  {p  ))OFF; 

EXDEVENT; 

Let  us  now  look  again  at  defined  functions.  Defined  functions  have  two  purposes. 
First,  they  may  be  required  in  the  specification  itself,  as  is  refs  of  paper  in  the  specification 
of  our  event  As  sign"  referee' to  paper.  Second,  every  query  can  be  regarded  as  no  more  than 
a  request  for  the  evaluation  of  a  function.  We  can  anticipate  some  queries,  and  the  answer 
to  an  anticipated  query  can  be  predefined:  if  it  is  the  value  of  a  basic  function,  nothing 
needs  to  be  done:  otherwise  a  defined  function  that  will  provide  an  answer  to  the  query  is 
introduced  in  the  schema  definition. 

In  the  SF  information  base  all  persistent  data  objects  belong  to  sets  and  maps.  The 
sets  are  arranged  in  hierarchies,  and  SF  provides  multiple  inheritance.  Multiple  inheritance 
can  be  of  two  kinds.  First,  an  object  of  type  X  can  inherit  properties  of  both  a  type  1’  and 
another  type  Z.  Second,  some  objects  of  type  X  may  inherit  the  properties  of  type  1'.  while 


other  objects  of  type  X  may  inherit  properties  of  type  Z.  In  SF  the  first  kind  of  inheritance 
is  handled  by  multiple  application  of  the  ISA.  and  the  second  by  set  partitioning  and  ISA. 
Thus,  for  a  boat  hiring  example  to  be  discussed  in  detail  further  on.  the  dependencies 
defined  by 


TYPE  B  (SUBSETS:  R  (SUBSETS:  F.  H.  OD.  M  ISA  Maintenance' object) 

ISA  Registered' ob ject .  DR) 

ISA  Water' vehicle  ISA  Hire' object". 


have  the  graphical  representation: 


In  this  diagram  ISA  links  are  represented  by  solid  lines;  subset  relationships  by  dashed 
lines.  The  subset  names  R  and  DR  are  abbreviations  for  Registered  and  Deregistered . 
respectively.  Subset  names  M.  OD.  H,  and  F  refer  to  boats  that  are  in  maintenance,  over¬ 
due  (i.e..  were  not  returned  when  expected),  hired,  and  free  for  hire. 

The  usefulness  of  inheritance  depends  on  how  easy  it  is  to  create  a  new  type  from  its 

parent  types.  Suppose  that  the  parent  types  have  available  functions  /  /  2 . /, . / l  • 

and  the  declaration  of  a  new  type  T  contains  functions  / . f  k  .  f  k  + , . f  „  .  Then  type 

T  inherits  functions  /  x.  f  2 .  / k  .  While  functions  /  j .  / ,  _x  may  not  be  changed  by 
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events  in  the  segment  of  T ,  functions  /, .  f  k  may  be  changed,  but  the  changes  are  not 

propagated  back  to  the  parent  segments.  » 

The  inability  to  make  changes  in  a  parent  type  is  a  special  case  of  the  genera!  principle 
that  no  SF  event  may  directly  change  an  object  that  does  not  belong  to  the  segment  in 
which  the  event  resides.  Suppose  that  type  B  is  the  basis  type  for  a  segment  Boat  hire. 
Then  no  event  in  this  segment  may  change  anything  in  an;,  other  segment,  say  one  that 
deals  with  repair  of  boats.  However,  we  may  import  types,  and  declare  instances  of  the 
imported  type  locally  in  the  importing  type.  Changes  may  then  be  brought  about  in  the 
locally  declared  instances.  For  example,  in  an  airline  reservation  system  customers  may 
have  to  be  put  into  waiting  lines.  The  type  of  queue  would  be  imported.  It  would  provide 
the  operations,  but  the  actual  queues  of  customers  would  reside  in  the  reservation  system 
as  locally  declared  instances. 

But  changes  can  be  brought  about  in  other  segments  indirectly.  This  is  by  message 
passing.  An  SF  message  (or  flag)  is  a  signal,  which  may  be  provided  with  arguments.  A 
signal,  after  it  has  been  raised  by  an  event,  is  picked  up  by  a  responder  transaction,  either  in 
the  same  segment,  or.  in  case  the  signal  is  declared  as  exported,  in  another  segment.  A  sig¬ 
nal  remains  alive  until  it  is  explicitly  turned  off.  A  variant  of  signals  consists  of  counters, 
which  may  be  incremented  or  decremented.  A  counter  remains  alive  until  its  value  drops 
to  zero.  Signals  also  provide  the  means  of  communication  between  segments.  Thus,  seg¬ 
ment  A  may  request  segment  B  to  perform  some  action  by  raising  a  flag.  This  flag  is 
exported  by  segment  A  and  imported  by  segment  B.  Segment  B  may  inform  segment  A  of 
the  completion  of  the  action  by  an  explicit  second  signal,  or  merely  by  turning  off  the  flag. 
The  interleaving  of  events  and  transactions  make  SF  processes  equivalent  to  Petri  nets,  with 
the  manipulation  of  signals  and  counters  corresponding  to  the  movement  of  tokens  in  a 
Petri  net. 

The  responder  processes  signals  immediately,  at  some  specific  time,  e.g.,  06:30  every 
morning,  or  at  set  intervals.  The  responder  initiates  events  on  its  own  accord,  prompts  the 
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user  tc  initiate  events,  or  reminds  the  user  that  some  action  is  to  be  performed.  For  exam¬ 
ple  in  a  system  that  manages  bank  accounts,  a  w  ithdrawal  e\em  may  cause  the  account  to 
become  overdrawn.  In  such  a  case  an  overdraft  signal  is  to  be  sent  to  the  responder.  A 
transaction  in  the  responder  now  initiates  an  event  that  assesses  a  penally  charge  against  the 
account,  and  reminds  the  account  manager  to  send  out  an  overdralt  nonce  to  the  customer. 
\\  e-ent  may  initiate  ano:her  e-en;  directly-- all  such  initiation1-  ha.e  to  be  carried  out  via 
transactions.  Events  initiated  by  the  responder  are  called  internal  events;  all  other  events 
are  external.  Internal  events  have  no  preconditions— all  input  data  associated  with  such 
events  are  assumed  to  have  been  already  checked.  Sometimes,  however,  the  responder 
establishes  that  external  events  are  to  be  initiated.  In  such  a  case  the  responder  issues 
prompts  to  the  user.  For  example,  in  the  assigning  of  referees  to  a  paper,  the  responder 
prompts  the  user  to  initiate  referee  assignment  events  until  the  required  number  has  been 
reached.  Reminders  issued  by  transactions  do  not  in  general  relate  to  events. 

The  separation  of  the  action  of  sending  out  a  message  (i.e.,  raising  a  signal  as  part  of 
an  event*  from  the  definition  ol  the  ultimate  effect  of  this  message  (in  a  responder,  which 
may  reside  in  a  different  segment)  has  several  pleasing  features.  First,  the  events  can  be 
defined  independently  of  the  responder,  and  all  decisions  regarding  the  precise  effect  of  a 
message  can  be  postponed.  Second,  because  messages  are  not  addressed,  more  than  one  tran¬ 
saction  can  pick  up  a  message,  w  hich  adds  to  the  flexibility  of  the  entire  system.  Third,  all 
indications  of  the  time  dependence  of  the  effect  of  a  message  belong  to  the  definition  of  the 
responder,  i.e..  the  specification  of  time-related  aspects  of  the  system  is  confined  to 
responders. 
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SF  SPECIFICATION:  BOAT  HIRE 


Our  first  example  of  an  SI  specification  relates  to  an  enterprise  that  hires  out  boats. 
Hiring  hours  are  9:00  u  20:00.  and  all  boats  must  be  back  b\  21:00  The  set  ol  interest  is 
that  of  boats  (B).  which  is  partitioned  into  the  subsets  of  registered  ( R )  and  deregistered 
(DR)  boats.  The  latter  are  no  longer  in  use.  i.e.,  have  been  scrapped.  The  set  of  registered 
boats  is  partitioned  into  free  (F).  hired  (H).  overdue  ( OD ).  and  "maintained"  (M)  boats. 
The  boats  in  set  M  are  to  be  inspected,  and  the  inspection  indicates  that  they  are  free  of 
defects,  to  be  repaired,  or  beyond  repair.  The  labels  in  secondary  set  STcode  correspond  to 
these  possibilities.  The  majority  of  the  events  move  boats  from  one  of  these  subsets  into 
another.  They  are  Hire  (which  moves  a  boat  from  subset  F  to  subset  H):  Return  (from  H 
to  F  or  to  MY.  Mark' o~ due  (from  H  to  OD.  applied  to  all  boats  that  ha\e  not  been  returned 
at  some  specified  lime  after  21:00):  Recover  (from  OD  to  A/):  Inspect  (from  F  to  A/): 
Maintenance'check  (from  M  to  F):  Reinstate  (from  M  to  F). 

Event  Buy  boar  brings  a  boat  into  the  enterprise:  event  Deregister  boat  takes  it  out. 
The  purpose  of  Heeds  analysis  is  to  update  a  parameter  that  indicates  how  many  additional 
boats  the  enterprise  needs.  Events  Deregister  boat.  Mark  o  due.  and  Reinstate  differ  from 
the  others  in  that  they  are  initiated  by  the  system  itself,  i.e..  they  are  internal.  Events  may 
have  certain  control  functions.  For  example,  when  a  boat  is  returned,  and  it  had  been  hired 
out  for  200  hours  or  more  since  its  last  inspection,  the  sigcondition  Check  condition  asks  the 
responder  to  initiate  a  maintenance  inspection  of  the  boat.  Such  an  inspection  is  mandatory 
when  an  overdue  boat  has  been  recovered. 

We  would  like  to  answer  rather  complicated  queries,  such  as  "What  is  the  total  time 
for  which  boat  x  has  been  hired  this  month?"  The  functions  of  the  type  B  serve  mostly 
this  purpose.  For  example.  Latest  hire  indicates  the  time  at  which  the  latest  hiring  event 
took  place  for  the  given  boat,  and  Ff  set  returns  a  set  of  triples  indicating  for  each  regular 


hiring  event  the  date  and  time  the  event  took  place,  as  well  as  the  length  of  the  interval  for 
which  the  boat  had  been  out. 

These  functions  require  the  importation  into  the  segment  under  consideration  of 
several  predefined  types:  T'min.  with  function  f  now'min  that  returns  the  current  time 
with  a  resolution  of  one  minute,  and  in  which  comparisons  are  standard  operations:  Date. 
again  with  comparisons,  and  the  function  D'  now  that  returns  the  current  date:  T  dur  min. 
which  consists  of  durations  of  time  intervals  measured  in  minutes,  and  in  which  subtrac¬ 
tion  of  times,  dates,  or  of  pairs  consisting  of  dates  and  times  are  standard  operations. 

Notation:  In  the  specification  of  an  event  a  primed  quantity  indicates  a  value  after  the 
event,  an  unprimed  quantity  indicates  a  value  before  the  event.  X-set  stands  for  the  power 
set  of  X.  Let  us  also  interpret  the  notation  in  the  specification  of  the  functionality  of 
If' sigma.  This  is  a  defined  function  in  the  sense  that  it  can  be  constructed  from  some  other 
function,  namely  If  set  here.  The  function  Coord  belongs  to  the  basic  type  of  maps— here  it 
extracts  the  third  coordinate  from  each  triple  in  the  range  of  H'set. 


SEGMENT  Boat' hire', 

IMPORTED  TYPE  fmin  ENDTYPE; 
IMPORTED  TYPE  Date  ENDTYPE: 
IMPORTED  TYPE  fdur'min  ENDTYPE: 


TYPE  B  (SUBSETS:  R  (SUBSETS:  F.  H,  OD.  M  ISA  Maintenance' object ).  DR) 

ISA  Water  vehicle  ISA  Hire  object: 


SECONDARYSETS-  S~code  -  |"ok".  "repair",  "scrap"!: 


FUNCTIONS—  Boat  ~in:  B 
Latest  ~ hire  :  R 

II  'set  :  R 

H  'sigma:  R 

H  'hist  :  B 

OD  set  :  B 


Date  : 

T  min: 

( Date  X  T'min  X  T  dur  min  )— set: 
T'dur'min  :  H  sigmaib  )  = 

AUop(  +  .  Coord  (H  'set  ( b  ).  3)): 
( Date  X  T'min  X  T  dur  min  )— set: 
{Dale  X  T'min  )— set: 
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RFC  set  :  B  — ♦  ( Date  X  T'min  )— set; 

ISSP'set  :  B  — •  Date—  set: 

Inspection  'code  :  M  — *  5  'code  ; 

Boat  shortage  :  — »  Integer  ; 

ENDTYPE: 

EVENT  Buy  boat  (boat): 

PRECONDITIONS—  not(  Member  (boa:  .  B  )): 
SETCONDITIONS—  F  =  F  JJ  {boat  J; 

MAPCONDITIONS—  Boat  inXboat  )  —  D  ' now  ; 

Boat  shortage  ‘  =  Boat  ~ shortage  —  1 ; 

EXDEVENT; 

INTERNAL  EVENT  Deregister' boatiboat): 

SETCONDITIONS-  R 1  =  R  -  ( boat  }  ; 

DR '  -  DR  U  | boat  }; 

MAPCONDITION'S—  Boat  shortage  ’  =  Boat  shortage  +1; 
EXDEVENT; 

EVENT  Seeds  analy sis(k :  Integer): 

MAPCONDITIONS-  Boat  shortage  '  —  Boat  shortage  +  k  ; 
ENDEVENT: 

EVENT  Hire(boat): 

PRECONDITIONS—  Member  (boat  ,  F  ): 

T  now  min  ^  20:00; 

SETCONDITIONS-  F  '  =  F  -  { boat  (; 

H'=H  \J  { boat  1: 

MAPCONDITIONS—  Latest  hire  '(boat  )  =  T  now  min ; 
ENDEVENT: 

EVENT  Return(boat): 

DEFINITIONS—  t  dur  :  T  now  min  — Latest  hire  (^oat  ); 
PRECONDITIONS—  Member  (boat  .  H  ); 

SETCONDITIONS-  H'  =  H  -  { boat  }: 


H  sigma'iboal  )  ^  200:00 — *  M  '  =  M  (J  \boal  }; 

H~sigma'(boat  )  <  200:00 — *  F‘  -  F  (J  { boat  i: 

MAPCONDITIONS-  H  'set  '(boat  )  =  H  'set  (boat  )  U  {  <D  now  ,  Latest  ~ hire  ( boat  ).  t  ~dur  >  ( 
S1GCONDITIONS—  H  sigma‘(boat  )  ^  200:00 — *  (Cheek  condition  (boat  ) )ON : 

EXDEVENT: 

INTERNAL  EVENT  Mark'o'due(boat): 

SETCONDITIONS—  H  ’  =  H  -  [boat ): 

OD '  =  OD  |J  {boat): 

MAPCONDITIONS—  OD  set  '(boat  )  =  OD  set  (boat  )  (_J  {  <D  now  .  Latest  ~ hire  (boat  )>  }; 
ENDEVENT. 

EVENT  Recover(boat): 

PRECONDITIONS—  Member  (boat .  OD  ); 

SETCONDITIONS-  OD'  =  OD  -  {boat }; 

M'  =  M  (J  { boat  }; 

MAPCONDITIONS-  RFC  'set  '(boat )  =  RFC  'set  (boat  )  u  {  <  D  now  .  T  now  min  >  ) ; 
SIGCOND1TIONS—  (Check  condition  (boat  ))ON; 

ENDEVENT: 

EVENT  Inspect(boat ): 

PRECONDITIONS—  Member  ( boat ,  F ); 

SETCONDITIONS-  F'  =  F  -  { boat  }: 

M'  =  M  (J  { boat  |; 

SIGCONDITIONS—  (Check  condition  (boat  ))ON: 

ENDEVENT; 

EVENT  M  aintenance' check  ( boat ,  status:  S'  code ) ; 

SETCONDITIONS-  status  ="ok"  — ► 

BLOCK  M'  =  M  -  { boat }; 

F‘  =  F  (J  {&>ar  }: 

ENDBLOCK; 

MAPCONDITIONS—  H'hist  '(boat  )  =  H'hist  (boat  )  (J  H'set  (boat  ); 

H  set  '(boat  )  =  Nullset  : 

INSP  set  '(boat  )  =  INSP  set  ( boat  )  (J  \D~now  }; 
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SIGCONDITIO.NS—  status  ="repair"  — *  [Re pair 'boat  ( boat  ))0\: 

status  ="scrap"  — *  1  Scrap  boat  (boat  ' K)\ 

(Check  condition  (boat  ))OFF; 

EXDEVENT: 

INTERNAL  EVENT  Reinstate! boat): 

SETCONDITIONS—  M  '  =  M  -  { boat  !: 

F,  =  f  [J  ( boat  |: 

ENDEVENT; 

TRANSACTION  Maintenance', 

@  (T  min  now  ):  Forall  ( x  ):  Member  ( x  ,  M  ):  ON  (Check  'condition  (x  ))ON— 

PROMPT( Maintenance  check  :  x  ); 

ENDTR  ANSACTION : 

TRANSACTION  O'due'check ; 

@  (21:15):  Forall  ( x  ):  Member  (.v  ,  H  ):  Mark  ~o  'due  (x  ): 

ENDTR  ANSACTION  : 

TRANSACTION  Check  needs'. 

Member  (D  now  +1,  EOM  dates  )  — *  PROMPT! Veecf 5  analysis  ): 

ENDTR  ANSACTION: 

TRANSACTION  Boat  purchase : 

Member  (D  now  ,  EOM  'dates  )  — *  PROMPTf’Buy  boat"):  TlMES(fioa/  'shortage  ): 
ENDTR  ANSACTION: 

TRANSACTION  Boat  repair'. 

(*  This  transaction  is  triggered  by  Repair~boat\  it  signals  some  other  segment--  the 
actual  repairs  are  undertaken  in  this  other  segment,  and  depend  on  availability 
of  resources:  the  flag  Boat  repaired  of  transaction  Backin'  service  is  set  by  some 
event  in  the  other  segment.  *) 

ENDTR  ANSACTION; 
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TRANSACTION  Back  in'  service: 

@  (T  min  now  ):  Forall  (x  ):  Member  (x  .  M  ):  ON(2?oat  repaired  (x  ))OFF—  Reinstate  (x  ); 

ENDTRANSACTION ; 

TRANSACTION  Send  out  searchers : 

Forall  (x  ):  Member  (x  .  OD  ):  REMIND("Find  boat":  x  ): 

ENDTRANSACTION: 

TRANSACTION  Scrapping"  of  boat: 

Forall  (x  ):  Member  (x  .  M  ):  ON  (Sera/)  boat  (x  ))OFF—  Deregister  "boat  (x  ); 

ENDTRANSACTION: 

TRANSACTION  Deregistration" test: 

Forall  (x  ):  Member  (x  .  OD  ):  D  "now  — 

Allop  (max.  {y  I  y  =  Coord  (OD'set  (x  ).  l)})  >  7  — *  Deregister  "boat  (x  ); 

ENDTRANSACTION; 

ENDSEGMENT: 

Transactions  are  of  two  types.  First,  transactions  that  are  to  take  place  at  a  given 
time  are  marked  with  the  symbol  e.g.,  @(21:15).  @(T'now~min )  In  our  example  one 
marked  transaction  is  to  take  place  at  21:15.  at  which  time  the  event  Mark"  o'  due  is  to  be 
initiated  for  all  hired  boats  that  are  still  out.  Unmarked  transactions  are  performed 
according  to  a  fixed  schedule,  which  is  once  a  day  in  our  case.  E.g.,  for  each  overdue  boat,  a 
reminder  is  issued  that  this  boat  is  to  be  looked  for.  As  another  part  of  this  daily  procedure 
the  current  date  is  compared  against  end-of-month  dates  (in  set  EOM" dates,  which  belongs 
to  type  Date).  ;  nd  transactions  Boat" purchase  and  Check" needs  are  initiated  on  an  end-of- 
month  date  or  the  day  preceding  it.  respectively.  Typically,  a  transaction  initiates  an  event, 
issues  a  reminder,  or  issues  a  prompt.  Reminders  do  not  in  general  relate  to  events.  On  the 
other  hand,  prompts  ask  the  user  to  initiate  events.  These  events  are  not  external,  but  the 
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system  cannot  initiate  them  on  its  own.  For  example,  the  purpose  of  event 
Maintenance' check  is  to  determine  what  is  to  be  done  to  a  boat  on  the  basis  of  the  value  of 
status.  However,  the  user  has  to  supply  this  value. 
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Formal  Specification  of  Software 


Support  Materials 


SF  Specification:  A  Library  System 


Aifs  Berztiss 
University  of  Pittsburgh 


One  of  the  problems  from  the  Fourth  International  Workshop  on  Software  Specification  and  Design  is  described 
and  solved  in  set-function  notation.  (Problems  from  this  workshop  appear  often  in  the  literature — instructors  are 
encouraged  to  look  for  comparative  examples  in  other  notations.) 
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SEI-SM-8-1.0 


SF  SPECIFICATION':  A  LIBRARY  SYSTEM 


The  library  system  is  another  oi  the  problems  selected  for  study  at  the  Fourth  Inter¬ 
national  Workshop  on  Software  Specification  and  design.  A  basic  requirement  is  that  the 
library  is  to  provide  for  multiple  copies  of  particular  titles.  This  means  that  a  distinction 
has  to  be  maintained  throughout  between  titles  of  books  and  copies  of  books.  We  shall  use 
the  term  book  only  when  this  term  could  indicate  either  a  title  or  a  copy.  An  informal 
statement  of  additional  requirements  and  constraints  on  the  system: 

•  copies  are  added  to  the  library  and  are  removed: 

•  copies  are  checked  out  and  returned  by  borrowers: 

•  every  copy  is  either  in  the  library  or  else  it  is  checked  out  to  a  borrower: 

•  no  more  than  a  predefined  number  of  copies  may  be  checked  out  to  a  borrower. 

The  system  is  to  have  these  minimal  query-answering  capabilities: 

•  listing  of  books  by  a  particular  author  or  in  a  particular  subject  area; 

•  listing  of  copies  that  are  checked  out  to  a  given  borrower  (restricted  to  library  staff 
except  that  borrowers  may  find  out  what  copies  they  themselves  have  borrowed): 

•  indication  of  the  name  of  the  borrower  who  last  checked  out  a  particular  copy  (res¬ 
tricted  to  library  staff). 

The  distinction  between  titles  and  copies  indicates  the  need  for  at  least  two  segments 
in  the  system.  The  segment  for  titles  then  relates  to  information  that  is  common  to  all 
copies  of  a  particular  book,  such  as  the  author  or  authors  and  the  subject  areas  of  the  book. 
Addition  or  removal  of  copies  can  have  an  impact  on  the  titles  segment.  Thus,  when  the 
very  first  copy  of  a  particular  title  arrives  at  the  library,  appropriate  information  has  to  be 
added  in  this  segment.  Again,  when  the  last  copy  of  a  title  is  removed,  the  information 
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regarding  this  title  is  not  deleted,  but  is  archived.  The  archiving  is  implemented  by  the  par¬ 
titioning  of  the  set  of  titles  into  subsets  INCAT  and  HASBEEN.  and  moving  the  title  from 
INCAT  into  HASBEEN.  Should  a  new  copy  of  the  book  become  again  part  of  the  library 
holdings,  then  the  title  is  restored  to  INCAT. 

The  primary  event  is  the  addition  of  a  copy  to  the  library,  but  this  event  requires  that 
the  title  be  already  registered  in  the  titles  segment.  Consequently  the  addition  of  a  first 
copy  is  somewhat  circuitous:  the  copies  segment  signals  the  titles  segment  that  a  new  title  is 
to  be  added;  after  the  title  has  been  added,  a  signal  goes  back  to  the  copies  segment  to  ini¬ 
tiate  addition  of  the  copy:  the  copy  is  finally  added  to  the  catalog. 


SEGMENT  Titles-. 

IMPORTED  SIGNALS  Add~ title,  Dr op~ title,  Move" title: 

EXPORTED  SIGNALS  Catalog" copy) 

IMPORTED  TYPE  Author  ENDTYPE; 

(*  Some  types,  such  as  Integer.  Boolean,  and  Text  are  assumed  to  be  universally 
available.  The  form  Subject" area:  Area  used  below  indicates  that  Area  is  an 
abbreviation  of  Subject" area.  *) 


TYPE  Title:  T  (SUBSETS:  INCAT,  HASBEEN)-. 

SECONDARY  SETS-  Subject  area :  Area ; 

FUNCTIONS—  title  text :  T  — *  Text  : 

authors  '.  T  — *  Author  —set: 
sub  jects  :  T  — *  Area  —set: 

ENDTYPE; 

EVENT  Add~title(neyvcopy\  book:  t:  Text :  A:  Author- set:  S:  Area-set): 

(*  The  types  of  arguments  t.  A  and  S  are  known,  and  are  indicated  in  the  list  of 
arguments;  book  has  not  yet  been  added  to  set  T,  i.e..  it  has  no  type;  newcopy 
is  an  argument  that  is  being  passed  through  from  the  copies  segment  back  to 
the  copies  segment,  where  it  will  become  part  of  the  set  C.  *) 


PRECONDITIONS-  not  (member  ( book  .  T )); 

SETCONDITIONS—  INCAT'  =  INCAT  [J  {600*}; 
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MAPCONDITIONS- 


dtle  ' text  ‘{book  )  =  t  ; 
authors  '{book  )  =  A  : 
sub  jects  '{book  )  =  S  ; 

SIGCONDITIONS—  ( Catalog  copy  ( newcopy  .  bmk  ))OM: 

EXDEVENT: 

INTERNAL  E\’EXT  React ivate{ newcopy.  book)'. 

SETCOXDITIOXS-  INCAT 1  =  INCAT  U  [book  J: 

HASBEEN 1  =  HASBEEN  -  ( book  }: 

SIGCONDITIONS—  {Catalog  ~ copy  {newcopy  .  book  ))ON: 

EXDEVENT: 

INTERNAL  EVENT  Drop~title{book); 

SETCOXDITIOXS-  INCAT  ‘  =  INCAT  -  { book  }: 

HASBEEN  •  =  HASBEEN  [J  [book  }; 

ENDEVENT; 

TRANSACTION: 

@  ( T  min  .  now  ):  ON  {Add  ~ title  {newcopy  .  book  ))OFF: 

PROMPTCAt/rf  title  :  newcopy  .  book  ): 

EN’DTR  ANSACTION ; 

TRANSACTION; 

@  ( T  min  .  now  ):  ON(  Drop  ~  title  {book  ))OFF:  Drop'title  {book  ); 

ENDTR  ANSACTION: 

TRANSACTION: 

@  {T  min  .  now  ):  ON( A/ove  title  {newcopy  ,  book  ))OFF:  Reactivate  {newcopy  .  book  ); 
ENDTR  ANSACTION: 

ENDSEGMENT; 
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SEGMENT  Copies: 

IMPORTED  SIGN  ALS  Catalog  copy ;  (*  This  signal  may  also  be  set  locally.  *) 

EXPORTED  SIGNAL  Drop  title.  Move' title ,  Add' title: 

IMPORTED  TYPE  Title:  T  ENDTYPE; 

IMPORTED  TYPE  Borrower :  B  ENDTYPE: 

TYPE  Copy:  C: 

(*  Values  in  parentheses  are  starting  values.  *) 


FUNCTIONS-  book  'id : 

C 

— >  T : 

borrowed  : 

C 

— *  Boolean  (false); 

last  'out : 

C 

— *  B  (nil): 

books  'out : 

B 

— *  Integer  (0); 

limit : 

— ►  Integer  (0); 

ENDTYPE; 

EVENT  Set' limit (k:  Integer): 

MAPCONDITIONS-  limit '  =  k  : 
ENDEVENT: 


EVENT  Check ~co pyinewcopy ,  book): 

SIGCONDITIONS—  member  ( book  .  INCAT  )  — »  ( Catalog  copy  (new copy  .  book  ))ON; 

member  ( book  .  HASBEEN  )  — >  (Move  title  (newcopv  .  book  ))ON 
not  (member  (book  .  T  ))  — >  (Add  'title  (newcopy  .  book  ))ON; 

ENDEVENT; 

INTERNAL  EVENT  Add  copy(newcopy ,  book): 

SETCONDITIONS—  C  *  =  C  u  [newcopy  }; 

MAPCONDITIONS—  book  id  '(newcopy  )  =  book  ; 

ENDEVENT; 

EVENT  Remove' copy  (copy): 

PRECONDITIONS—  member  (copy  .  C  ): 

not  (borrowed  (copy  )); 
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SETCONDITIONS-  C‘  =  C  -  f copy  }: 

SIGCONDITIONS-  card  ({.r  I  book  'id  tr  )  =  book  'id  ( copy  )})  =  0 

— *(Drop  'title  ( book  'id  ( copy  )))ON; 

EXDEVENT; 

EVENT  Check' out(copy .  borr:  B ); 

PRECONDITIONS-  member  (copy  .  C  ); 

not  (borrowed  ( copy  )): 
books  out  (borr  )  <  limit  ; 

MAPCONDITIONS—  borrowed  '(copy  )  =  true; 

last  'out  '(copy  )  =  borr  ; 

books  out  '(borr  )  =  books  out  (borr  )  +  1 ; 

ENDEVENT; 

EVENT  Check' in(co py ,  borr:  B)\ 

PRECONDITIONS-  member  (copy  .  C  ); 

last  'out  (copy  )  =  borr  ; 

MAPCONDITIONS—  borrowed  '(copy  )  =  false: 

books  'out  '(borr  )  =  books  out  (borr  )  —  1; 

ENDEVENT; 

TRANSACTION: 

@  ( T  min  .  now  );  0'S(Catalog  copy  (newcopy  .  book  ))OFF:  Add  copy  (newcopy  .  book  ); 
ENDTRANS  ACTION; 

EXDSEGMEXT: 

The  answers  to  queries  are  simply  values  of  functions  for  given  arguments.  Thus 
last'out(copy)  returns  the  last  borrower  of  a  copy.  However,  to  determine  the  set  of  books 
checked  out  to  borrower  x,  we  need  a  defined  function 

out  'set  :  B  — *  C  —set:  out  set  (x  )  = 

(y  I  last  'out  (y  )  =  x  A  borrowed  (y  )}. 

Note  now  that  function  out' set  makes  the  explicit  map  btxsks'oui  redundant: 
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books  ~ out  :  B  — »  Integer  :  books  ~out  (x  )  =  card  ( out  ~set  (x  )). 

Queries  regarding  books  by  subject  matter  or  by  author  can  be  given  several  interpre¬ 
tations.  Under  one  interpretation  the  answer  should  be  a  listing  of  titles,  irrespective  of 
whether  any  copies  of  a  particular  title  are  indeed  current lv  in  the  library.  Under  a  second 
interpretation  all  currently  available  copies  should  be  listed.  Actually  the  most  useful 
response  seems  to  be  a  listing  of  all  titles  of  which  at  least  one  copy  is  currently  available: 

titles  'by  ~ topic  :  Area  — *  T  —set: 

titles  ~by  ~ topic  (x  )  =  {y  I  member  (x  ,  sub  jects  (y  ))  A  member  (y  ,  INCAT  )  A 

Allop  (V ;  {  no\(borrowed  {:  ))  I  book'id(z)  =  y  })}. 

The  definition  of  titles  by  author  is  analogous. 

Let  us  now  consider  authorization.  Evaluation  of  functions  titles' by' topic  and 
titles' by' author  can  be  requested  by  everyone.  However,  evaluation  of  books' outlx)  can  be 
requested  only  by  a  librarian  or  by  borrower  x.  This  restriction  takes  care  of  itself  if  the 
identifiers  of  borrowers  are  known  only  to  borrowers  themselves  and  to  the  library  staff, 
i.e..  one  must  know  x  to  access  books'out(x).  Only  librarians  may  initiate  events. 
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This  is  another  example  from  the  Fourth  International  Workshop  on  Software  Specification  and  Design,  also 
solved  in  set-function  notation.  This  problem  is  more  complicated  than  the  library  problem. 
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SF  SPECIFICATION':  AN  ELEVATOR  CONTROLLER 


The  elevator  controller  is  the  third  problem  selected  for  study  at  the  Fourth  Interna¬ 
tional  Workshop  on  Software  Specification  and  design.  Here  the  specification  is  to  indicate 
the  responses  of  a  system  to  user  requests.  Each  elevator  has  a  set  of  buttons,  one  for  each 
floor.  They  light  up  when  pressed,  and  the  elevator  is  then  to  visit  the  indicated  floor.  The 
light  goes  off  when  the  elevator  halts  at  this  floor.  The  lit-up  buttons  define  an  agenda  for 
the  elevaior.  No  floor  can  be  added  to  the  agenda  that  is  not  in  the  current  direction  of 
travel.  All  lights  go  off  when  a  sensor  determines  that  the  elevator  is  empty.  An  elevator 
with  an  empty  agenda  is  in  an  idle  state. 

Floors  have  outside  buttons,  to  request  up-  or  down-elevators.  An  outside  button  also 
lights  up  when  pressed,  and  the  light  goes  off  when  an  elevator  going  in  the  appropriate 
direction  visits  this  floor.  The  system  should  give  equal  priority  to  each  outside  request. 

Each  elevator  has  a  stop  button.  Pushing  in  of  this  button  causes  the  elevator  to  go 
out  of  service  if  it  is  at  a  floor,  or  to  go  out  of  service  after  reaching  the  next  floor  if  it  is 
between  floors.  The  stop  is  terminated  by  pulling  out  the  stop  button. 

We  propose  two  segments.  Elevator  and  Dispatcher.  Suppose  the  system  consists  of  k 
elevators.  The  elevator  segment  is  to  specify  the  operation  of  one  such  elevator  in  terms  of 
the  agenda.  At  implementation  time  k  processes  will  be  instantiated  from  this  specification. 
The  dispatcher  segment  is  to  look  after  the  servicing  of  outside  requests.  The  dispatcher 
would  add  floors  to  the  agendas  of  the  individual  elevators,  and  send  idle  elevators  to  hold¬ 
ing  floors  in  order  to  provide  efficient  service.  The  dispatcher  operation  would  be  deter¬ 
mined  by  a  complicated  scheduling  algorithm,  but  the  development  of  algorithms  is  a  func¬ 
tion  of  design  rather  than  of  specification.  In  other  words,  the  purpose  of  specification  is  to 
indicate  what  a  system  is  to  accomplish,  not  how  it  is  to  do  this.  Consequently  we  can 
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define  Elevator  fully,  bui  as  regards  Dispatcher ,  can  do  no  more  than  pass  through  to  the 
design  stage  the  requirement  that  the  system  of  elevators  be  fair. 


The  operation  of  an  elevator  can  be  looked  at  as  transition  between  slates,  as  shown  in 
the  figure  above.  When  the  elevator  is  in  motion,  it  is  either  in  an  up  or  in  a  down  state. 
When  it  halts  at  a  floor,  there  is  a  transition  to  an  uphalt  or  a  dhalt  state,  respectively. 
From  a  halt  state  it  can  resume  motion,  become  idle,  or  be  stopped.  The  elevator  can  also  be 
stopped,  i.e..  taken  out  of  action,  when  it  is  in  motion.  There  are  two  stop  states,  upsiop 
and  dstop,  because  there  are  two  possible  stales  of  motion  that  the  elevator  can  attain  on 
resuming  motion  after  passing  into  a  halt  state  from  a  stop  state.  The  elevator  is  taken  out 
of  the  idle  state  by  the  dispatcher. 

Actually  the  dispatcher  can  influence  the  operation  of  an  elevator  in  three  ways:  an 
idle  elevator  may  be  moved  to  a  particular  floor:  an  idle  elevator  may  be  brought  out  of  the 
idle  state:  an  elevator  rn  the  up  or  down  state  or  in  one  of  the  halt  states  may  have  a  floor 
added  to  its  agenda.  The  respective  signals  are  Move  idle.  Activate  elevator.  Add' to' agenda. 


Another  way  of  looking  at  the  actions  of  an  elevator  is  in  terms  of  sequences  of 
events.  Such  sequences  can  be  regarded  as  processes.  The  mechanism  for  defining  a  process 
is  provided  by  SF  signals,  e.g..  event  A  sets  flag  F.  and  a  responder  transaction  initiates 
event  B  on  account  of  flag  F  having  been  set.  Such  interleaving  of  events  and  transactions 
suggests  the  use  of  Petri  nets  to  model  the  sequencing  of  events.  This  will  be  discussed 
further  on. 

The  methodology  used  in  the  specification  of  the  elevator  differs  in  some  ways  from 
that  used  in  the  specification  of  the  library  system.  One  difference  is  that  we  introduce  a 
special  class  of  functions  that  we  call  sensors.  They  are  actually  devices  that  supply  a 
value  on  demand.  One  sensor  ( nidlweight )  indicates  whether  the  elevator  is  empty;  another 
( floor' now )  indicates  the  floor  at  which  the  elevator  is  currently  located.  There  is  also  the 
Next' floor' sensor ,  which  is  a  signal  that  is  set  whenever  the  elevator  passes  a  special  sensor 
in  its  travel  between  any  two  floors.  This  signal  initiates  an  event  {Passing' sensor)  that 
determines  whether  the  elevator  is  to  continue  in  motion  or  is  to  halt  at  the  next  floor. 

Continuation  of  motion  or  halting  is  regulated  by  two  signals  that  enable  segment 
Elevator  to  communicate  with  the  mechanical  controls  of  the  elevator,  namely  the  signals 
Motion  up  and  Motion  down.  Very  similar  is  the  signal  Door  open',  it  causes  the  elevator 
door  to  open  when  it  is  on.  and  the  elevator  door  to  close  when  it  is  off.  The  elevator  is 
stopped  by  means  of  event  Stop' elevator,  which  is  initiated  by  the  pressing  of  a  stop-button 
inside  the  elevator.  This  event  causes  an  alarm  to  sound  (by  means  of  the  signal  Alarm). 
The  reciprocal  event  Reactivate' elevator  stops  the  alarm.  There  are  also  signals  to  control 
the  illumination  of  floor  indicators:  Light,  one  for  each  floor  selection  button  within  the 
elevator,  and  U plight  and  Dlight.  which  are  two  buttons  by  which  elevator  service  for  going 
up  or  going  down  can  be  requested  from  the  outside  (of  course  the  bottom  and  top  floors 
have  just  a  single  button).  We  refer  to  these  signals  collectively  as  mechanisms. 
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FOMENT  Elevator ; 


IMPORTED  SIGNALS  Activate  elevator,  Add' to' agenda.  Move' idle'. 

SENSOR  SIGNALS  Next  floor  sensor', 

MECHANISMS  Door  open.  Alarm,  Light,  Uplight,  Dlight.  Slotion  up.  Motion  down', 
IMPORTED  TYPE  Time:  T  ENDTYPE; 

IMPORTED  TYPE  Time' interval:  T I  ENDTYPE: 

TYPE  Elevator:  E: 

SECONDAR\  SETS—  S  =  {"idle",  "up",  "uphalt",  "upstop",  "down",  "dhalt",  "dstop"}; 

Floor  :  F  =  Integer  ; 

FUNCTIONS-  state  :  E  — *  S  : 

low  floor :  E  — *  F : 

highfloor  :  E  — *  F ; 

clock  :  E  — *  T : 

delay  :  E  — *  TI : 

agenda  \  E  XF  — >  Boolean  (false); 

SENSORS—  floor  'now  :  E  — *  F ; 

nullweight  :  E  —*  Boolean  ; 

ENDTYPE: 

EVENT  Initialize' elevatorie:  low,  high:  F:  interval:  TI): 

(  Parameter  interval  indicates  the  time  for  which  the  elevator  door  is  to  be  kept 
open  after  it  was  last  opened  or  a  person  stepped  through  it.  *) 

MAPCONDITIONS-  state  ’(e  )  =  "idle"; 

low  floor  ‘(e  )  =  low  ; 
highfloor  '( e  )  =  high  ; 
delay  '{e  )  =  interval  ; 

ENDEVENT; 

INTERNAL  EVENT  Activate' elevator(e:  x:  S): 

(*  Initiated  by  the  dispatcher  via  signal  Activate' elevator .  *) 

MAPCONDITIONS-  state  Xe)  =  x: 

clock  ‘(e  )  =  T.now  ; 
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SIGCONDITIONS 


( Door  ~ open  )ON: 

x  =  "uphalt"  — *  (Uplight  ( floor  ~now  ( e  )))OFF; 
x  =  "dhalt"  — *  ( Dlight  (  floor  ~now  (e  )))OFF; 

( Process  halt  (e  ))ON; 

ENDEVENT; 

INTERNAL  EVENT  Enter  halt(e): 

MAPCONDITIONS—  agenda  ‘(e  ,  floor  ~now  (e  ))  =  false: 

noi(nullweight  (e  ))  — »  clock  ‘(e)  =  T  now  ; 

SIGCONDITIONS—  not (nullweight  (e  ))  — > 

BLOCK 

(Door  ~ open  (e  ))ON; 

state  (e  )  =  "uphalt"  — +  (U plight  ( floor  ~ now  (e  )))OFF: 
state  (e)  —  "dhalt"  — *  (Dlight  ( floor  ~now  (e  )))OFF: 

(Light  (e  .  floor  ~now  (e  )))OFF: 

(Process  ' halt  (e  ))ON: 

ENDBLOCK; 

nullweight  (e  )  — »  (Idle  ~ elevator  (e  ))ON: 

ENDEVENT; 

EVENT  Press~button(e:  floor:  F): 

(*  Only  floors  in  the  direction  of  travel  of  the  elevator  may  be  added  to  the 
agenda.  *) 

PRECONDITIONS—  state  (e  )  =  "up"  V  state  (e  )  =  "uphalt"  — *  flixir  >  floor  ~ now  (e  ): 

state  (e  )  =  "down"  V  state  (e  )  =  "dhalt"  — *  floor  <  flcwr  now  (e  ) 
not  (member  (state  (e  ).  {"idle",  "upstop".  "dstop"!)): 
MAPCONDITIONS—  agenda  '(e  ,  floor  )  =  true: 

SIGCONDITIONS-  (Light  (e  .  floor  ))ON; 

ENDEVENT: 

INTERNAL  EVENT  Add~ to  agenda(e\  floor :  F): 

(*  Initiated  by  the  dispatcher.  *) 

MAPCONDITIONS—  agenda  '(e  .  floor  )  =  true: 

ENDEVENT; 
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INTERNAL  EVENT  Process' halt(e); 


SIGCONDITIONS- 


ENDEVENT; 


Allopi A;  (not (agenda  (e  .  x  ))  I  lowfioor  ( e  ^highfloor  (e  )i)  — * 

( Idle  ~ elevator  (e  ))ON; 

Allop{\I ;  {agenda  (e  .  x  )  I  lowfioor  ( e  )^.t  ^ highfloor  ( e  )))  — * 

(Ser  'in'motion  (e  ))ON; 


INTERNAL  EVENT  Set'in'motionie ); 
MAPCONDITIONS- 


SIGCONDITIONS— 


ENDEVENT; 


state  (e  )  =  "uphalt"  — *  state  '( e  )  =  "up": 
state  (e  )  =  "dhalt"  — *  state  ‘(e  )  =  "down"; 

( Door  ~ open  ( e  ))OFF; 

state  (e  )  =  "uphalt"  — *  ( Motion  ~up(e  ))ON; 
state  (e  )  =  "dhalt"  — *  ( Motion  ~down(e  ))ON; 


INTERNAL  EVENT  Passing' sensor(e): 

MAPCONDITIONS-  agenda  (e  .  floor  ' now  (e  )+ 1 ) 


SIGCONDITIONS— 


— *  state  Xe  )  =  "uphalt": 
agenda  (e  .  floor  'now  ( e  )— 1)  — *  state  '(e  )  =  "dhalt": 

agenda  ( e  ,  floor  now  (e  )+l)  — *  ( Motion  up{e  ))OFF; 

agenda  (e  ,  floor  now  (e  )— 1 )  — *  ( Motion  downie  ))OFF; 

agenda  (e  ,  floor  now  {e  )+ 1 )  V  agenda  (e  ,  floor  'now  {e  )— 1 ) 

( Enter  halt  (e  ))ON: 


ENDEVENT: 


EVENT  Stop  elevator(e): 


MAPCONDITIONS— 


SIGCONDITIONS— 


ENDEVENT; 


slate  (e  )  =  "down"  V  state  (e  )  =  "dhalt"  — * 

state  '(e  )  =  "dstop"; 
state  (e  )  =  "up"  V  state  (e  )  =  "uphalt"  — > 

state  Xe  )  =  "upstop"; 

state  (e  )  =  "down"  — *  ( Motion  ~down{e  ))OFF; 
state  (e  )  =  "up"  — *  ( Motion  ~up(e  ))OFF; 

( Alarm  ( e  ))ON; 

( Door  'open  (e  ))ON: 
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EVENT  Reactivate'  elevator{e): 


MAPCONDITIONS- 

SIGCONDITIONS- 


ENDEVENT; 


state  '( e  )  =  "upstop"  — *  state  (c  )  =  "uphalt": 
state  '{e  )  =  "dstop"  — *  state  (e  )  =  "dhalt"; 

( Alarm  (e  ))OFF: 

{Enter 'halt  (e  ))ON; 


INTERNAL  EVENT  Idle'elevator(e): 

MAPCONDITIONS—  state  '{e  )  =  "idle": 

Allop  (A ;  {not (agenda  '( e  ,  x  ))  I  lowfloor  ( e  )^x  ^ highfloor  (e  )(); 
SIGCONDITIONS—  Allop  (A ;  {{Light  (e  ,  x  ))OFF  I  lowfloor  (e  Kx  < highfloor  (e  )>); 

{Door  open  {e  ))OFF; 

ENDEVENT: 


INTERNAL  EVENT  Move'idle{e:  floor:  F); 

{*  Initiated  by  the  dispatcher.  *) 

MAPCONDITIONS—  agenda  '{e  ,  floor  )  =  true: 

floor  >  floor  'now  (e  )  — *  state  '{e  )  =  "uphalt". 
floor  <  floor  now  {e  )  — *  state  ‘{e  )  =  "dhalt", 
SIGCONDITIONS-  {Set  'in'motion  {e  ))ON; 

ENDEVENT; 

EVENT  Update  clock{e)\ 

{*  Initiated  by  breaking  a  light  beam  across  the  door  of  the  elevator  or  by 
some  similar  device.  *) 

MAPCONDITIONS-  clock  '{e  )  =  T.now  ; 

ENDEVENT: 


EVENT  Open  door(e): 

{*  This  event  is  required  for  people  to  get  out  who  somehow  find  themselves  in 
an  idle  elevator.  Raising  the  flag  Process~ha.lt  ensures  that  the  opened  door 
will  ultimately  close  again.  *) 
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MAPCONDITIOXS—  clock  \e  )  =  T.now  ; 

SIGCO\DITIO\S—  (Door'open  (e  ))0\; 

( Process  ~ halt  ( e  ))ON; 

ENDEVENT: 

TRANSACTION: 

@  (T.now  ):  (A\(Activate  elevator  ( c  ) )( )FF :  Activate  elevator  (e  ); 
ENDTRANSACTION: 

TRANSACTION: 

@  ( T.now  ):  O \(Add  to  agenda  ( e  ,  floor  ))OFF:  Add  to  agenda  (e  .  floor  ): 
ENDTRANSACTION ; 

TRANSACTION: 

@  ( T.now  ):  ON(A/ove  idle  (e  ,  floor  ))OFF:  Move  idle  (e  ,  floor  ); 

ENDTRANSACTION: 

TRANSACTION: 

@  ( T.now  ):  ON  (Enter  'halt  (e  ))OFF:  Enter  ~ halt  (e  ); 

ENDTRANSACTION: 

TRANSACTION; 

(*  The  delay  is  to  give  passengers  lime  to  press  destination  buttons.  *) 

@  (clock  (e  )+delav  (e  )):  ON( Process  ~ halt  (e  ))OFF:  Process  'halt  (e  ): 
ENDTRANSACTION; 

TRANSACTION; 

@  (T now  ):  ON(Ser  in  motion  ( e  ))OFF:  Set  'in'motion  ( e  ); 
ENDTRANSACTION; 


TRANSACTION: 


@  (T.now  ):  ON( Next  floor  ~ sensor  (e  )) OFF:  Passing  sensor  (e  ): 
ENDTR  ANSACTION : 

TRANSACTION: 

@  (T.now  ):  O Xildlc  elevator  (e  ) )OFF:  Idle  elevator  (c  ); 

ENDTR  ANSACTION ; 

ENDSEGMENT; 
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elevator  problem  (previous  section)  is  discussed  at  the  end  of  this  section. 
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THE  SPECIFICATION'  PROCESS 


SEGMENTATION  OF  SF  SPECIFICATIONS 

The  initial  task  in  the  specification  process  is  to  define  the  segments.  Discussions  with 
clients  and  within  specification  groups  establish  a  common  vocabulary.  For  the  most  part 
data  types  derive  from  nouns  in  the  vocabulary,  events  from  verbs.  Functions  are  defined 
in  anticipation  of  the  queries  that  will  be  put  to  the  system  or  of  the  support  needs  for  the 
control  activities  of  the  system.  (The  information  needed  to  evaluate  preconditions  of 
events  can  be  regarded  as  provided  by  internal  queries.)  At  this  stage  no  thought  should  be 
given  to  responders  or  signals.  Nevertheless,  the  initial  scheme  will  become  modified  a  few 
times. 

Alternatives  will  have  to  be  weighed  one  against  another.  For  example,  a  withdrawal 
from  an  account  may  be  considered  as  an  event  that  modifies  functions  belonging  to  seg¬ 
ment  account.  Aliernatixely.  withdrawal  could  itself  be  a  segment.  There  would  still  be  a 
withdrawal  event,  but  this  event  would  modify  functions  of  segment  withdrawal.  Of 
course,  withdrawals  also  affect  balances  in  accounts,  but  the  balance  adjustments  can  be 
accomplished  by  means  of  signals  that  initiate  internal  es  ents  in  account. 

It  is  important  to  realize  that  there  is  no  "best"  solution,  although  we  do  recommend 
that  each  segment  be  identified  with  a  data  type.  The  first  factor  to  affect  segmentation  is 
the  client’s  viewpoint.  If  the  primary  purpose  of  the  banking  system  is  to  provide  informa¬ 
tion  regarding  accounts,  then  there  may  not  be  a  need  for  a  separate  withdrawals  segment. 
But  the  need  may  exist  if  the  primary  purpose  is  to  control  the  processing  of  withdrawals. 
In  other  words,  the  segmentation  should  correspond  to  a  partitioning  of  the  system  that 
seems  natural  to  the  client.  Therefore  it  is  necessary  to  hold  extensive  consultations  with 
representatives  of  the  client.  It  is  essential  that  the  segment  structure  be  found  acceptable 
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by  these  representatives  before  further  work  is  undertaken.  Unfortunately,  a  realistic 
client-specifier  interaction  is  difficult  to  provide  for  student  projects. 

Second,  segmentation  assists  in  the  distribution  of  labor.  If  a  team  of  four  is  to 
specifv  an  elevator  controller,  then  a  separation  of  the  system  into  four  equal  segments 
may  be  appropriate,  but  equality  (of  size  or  difficulty.)  of  segments  is  hard  to  achieve.  A 
group  of  four  students  that  worked  on  the  specification  of  an  elevator  used  segments 
get~calls  (to  collect  destination  indications  from  within  and  calls  for  service  from  without 
the  elevator),  ad d~ floors  (to  set  up  an  agenda),  move' elevator  (to  see  to  the  actual  movement 
of  the  elevator,  both  when  it  is  responding  to  users  and  when  it  is  idle),  dispatcher  (to 
switch  agendas),  abnormal' stop  (to  deal  with  the  pressing  of  the  stop  button),  and 
power' on  off  (to  deal  with  power  failures). 

Some  of  these  segments  consist  merely  of  events  and  the  responder,  which  goes  against 
our  earlier  recommendation  that  segments  be  data  types.  Although  the  approach  was 
justified  here,  in  the  long  run  excessive  segmentation  causes  a  heavy  traffic  of  messages 
between  segments.  Therefore,  after  the  segments  have  been  developed  by  members  of  the 
specification  team,  and  the  initial  design  tested  by  some  static  analysis  technique,  such  as  a 
walkthrough,  segments  should  be  amalgamated.  This  is  a  very  simple  process  in  that  the 
existing  messages  will  still  be  needed,  but  they  will  now.'  be  passed  along  internally  between 
components  of  the  same  segment. 

Other  important  decisions  relate  to  type  hierarchies.  How  should  the  ISA  facility  be 
used9  When  is  it  better  to  have  a  hierarchy?  When  is  it  better  to  have  independent  seg¬ 
ments?  For  a  while  we  toyed  with  the  idea  that  the  titles  and  copies  of  the  library  system 
should  somehow  be  made  into  a  hierarchy,  but  finally  rejected  the  idea  as  counterintuitive. 
The  statement  "X  ISA  Y*  only  makes  sense  for  X  a  subset  of  Thus,  in  the  boat  example, 
the  set  of  boats  in  the  system  is  a  proper  subset  of  all  objects  available  for  hire,  and  this  set 
of  boats  is  also  a  subset  of  all  water  vehicles.  Actually  we  could  have  refined  the  second 
subset  relation  by  stating  that  our  set  of  boats  is  a  subset  of  the  set  of  all  boats,  with  the 
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latier  being  declared  a  subsel  of  all  water  vehicles. 

The  set  of  titles,  on  the  other  hand,  defines  a  partition  superimposed  on  the  set  of 
copies.  Whereas  every  boat  is  a  water  vehicle,  one  copy  corresponds  to  one  title,  and 
another  copy  corresponds  to  another  title.  The  ISA  should  not  be  used  to  define  aggrega¬ 
tions  either.  For  example,  a  car  mav  be  composed  of  four  wheels,  a  chassis,  etc.  This  means 
neither  that  “car  ISA  wheel" .  nor  that  “wheel  ISA  car" . 

Once  the  precise  structure  of  the  segments  has  been  fixed,  the  pre-.  set-,  and  mapeondi- 
tions  of  the  events  can  be  filled  in.  To  avoid  oversights,  a  list  of  all  the  functions  of  the 
data  type  should  be  consulted  whenever  a  new  event  is  being  defined,  to  check  that  all 
effects  of  the  event  are  indeed  being  considered.  At  this  stage  the  need  for  additional  func¬ 
tions  may  become  felt. 

An  important  tool  for  identifying  all  the  objects  or  entities  that  are  to  be  the  concern 
of  an  information-control  system,  and  for  relating  these  entities  to  each  other  is  Chen's 
Entity-Relationship  (E-R)  approach.  It  is  primarily  a  graphical  device  for  displaying  a 
static  model  of  an  enterprise.  There  are  two  kind  of  boxes:  rectangles  for  entity  sets,  and 
diamonds  for  relationship  sets.  Boxes  are  linked  by  undirected  lines,  and  the  two  boxes 
linked  by  a  line  differ  in  kind.  Further,  both  entity  sets  and  relationship  sets  may  have 
attributes.  An  attribute  of  a  set  is  indicated  by  an  ellipse,  and  there  is  an  arrow  from  the 
box  representing  the  set  to  the  ellipse. 

As  an  illustration  we  show  an  E-R  diagram  for  an  information  system  that  relates 
students,  courses,  and  instructors.  There  are  two  relationships.  Takes  and  Gives.  The  labels 
N  and  M  mean  that  Takes  is  a  many-to-many  (iV-to-A/)  relation,  and  labels  N  and  1  mean 
that  Gives  is  many-to-one  from  Course  to  Instructor  (or  one-to-manv  from  Instructor  to 
Course).  We  also  show  some  of  the  attributes  of  Course,  and  an  attribute  of  Gives.  The 
latter  indicates  whether  a  given  instructor  teaches  a  given  course  on  a  regular  basis  or  under 
some  special  arrangement. 
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E-R  model  of  a  section  of  a  university  information  system 


The  equivalent  SF  specification  consists  of  three  components  -  Students,  Courses,  and 
Instructors.  The  Reg/Spec  attribute  has  to  be  associated  either  with  type  Course  or  type 
Instructor.  Here  it  is  associated  with  Instructor.  We  show  here  just  the  three  type 
specifications. 

TYPE  Studenr.  S: 

FUNCTIONS-  takes  :  S  — *  C  -set: 

.  (Functions  that  are  attributes  in  E— R) 

ENDTYPE; 

TYPE  Course:  C: 

FUNCTIONS—  roster  :  C  — *  S  —set:  roster  (x  )  = 

{y  I  member  ( x  .  takes  (y  ))}; 


instructor  ' of  : 

C  — *  F: 

locale  : 

C  — *  Room 

meets  'at  : 

C  — *  T: 

size  limit: 

C  — »  /: 
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(Further  attribute  functions) 


ENDTYPE: 

T\  PL  Instructor:  }■  '. 

SECOXDAR  VSI'TS-  Teaching  status:  TS  =  {"RE G"  "SPlC"l : 

FUNCTIONS—  gives  :  F  — *  C  —set:  gives  (x  )  = 

{y  I  instructor  'of  {y  )  =  x  j; 

status  :  F  x  C  — »  TS  : 

.  (Attribute  functions) 


ENDTYPE; 

The  E-R  philosophy  is  to  differentiate  between  relations  and  attributes.  Relations  are 
between  entities  that  belong  to  the  E-R  model:  attributes  are  maps  from  an  entity  or  a  rela¬ 
tion  to  a  data  type  that  is  external  to  the  model.  However,  with  the  separation  of  the 
model  itself  into  segments  such  a  distinction  becomes  rather  arbitrary  and  artificial.  Furth¬ 
ermore.  the  vocabulary  is  increased  unnecessarily.  Nevertheless,  the  development  of  an  E- 
R  model  of  an  information  system  is  certain  to  contribute  to  a  better  understanding  of  the 
interrelation  of  the  elements  of  the  information  system,  and  is  therefore  recommended  as  a 
preliminary  to  SF  specification. 

THE  DYNAMIC  COMPONENT  OF  SF  SPECIFICATIONS 

The  final  stage  in  SF  specification  is  the  addition  of  the  dynamic  (or  time-dependent, 
or  control)  component.  This  consists  of  sigeonditions,  the  responder,  and  internal  events. 
In  some  cases  the  dynamic  component  is  a  fairly  minor  addition,  such  as  in  the  library 
example.  Surprisingly,  in  all  our  experience,  the  addition  of  the  dynamic  component  has 
required  no  or  very  minor  changes  to  the  static  part  of  the  specification. 
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We  have  found  state-transition  diagrams  and  Petri  nets  of  great  assistance  in  the  writ¬ 
ing  of  SF  specifications.  An  example  of  a  state-transition  diagram  has  already  been  given 
for  the  elevator  problem.  For  the  boat-hire  problem  the  appropriate  state-transition 
diagram  is  as  follows: 


A  (place-transition)  Petri  net  consists  of  a  digraph  and  a  dynamically  changing  mark¬ 
ing  pattern.  The  digraph  consists  of  two  disjoint  sets  of  nodes,  places  P  and  transitions  T 
and  a  flow  relation  F  £  (P  XT )  (J  (T  XP ).  Given  transition  t,  the  set  of  places 

{p\<p  .  t  >€/*)  is  the  preset  of  t  and  the  set  of  places  \p  i  <t  ,  p  >  €F  j  is  the  postset  of  t. 

Presets  and  postsets  of  places  are  defined  analogously.  Places  are  usually  represented  by 
circles,  transitions  by  bars.  Each  place  has  associated  with  it  a  class  of  token  types.  Tokens 
of  different  types  may  be  distinguished  by  drawing  them  in  different  colors  or  by  use  of 
different  symbols.  An  initial  marking  provides  each  place  with  zero  or  more  tokens  of  each 
of  the  types  associated  with  this  place,  and  the  net  is  then  in  its  initial  state.  The  net 
changes  states  by  firings.  A  firing  of  a  transition  is  enabled  if  each  place  in  its  preset  holds 
at  least  one  token  of  each  of  the  types  associated  with  that  place.  The  result  of  the  firing  is 
twofold.  First,  for  each  place  in  the  preset,  one  token  of  each  of  the  types  associated  with 
that  place  is  removed.  Second,  for  each  place  in  the  postset.  a  token  of  each  type  associated 
with  this  place  is  added.  Tokens  may  also  be  added  during  the  running  of  a  Petri-net  pro¬ 
cess  as  inputs.  In  the  examples  to  be  discussed  here  all  tokens  will  be  of  the  same  type. 

Note  that  we  shall  use  Petri  nets  primarily  as  a  graphical  tool.  An  investigation  of  the  uses 


49 


of  the  formal  theory  underlying  Petri  nets  in  the  analysis  of  control  systems  is  outside  our 
scope. 


T6:  n  =  0 


Tl:  f:=  1 


T2:  f:=  f*k 


T3:  k:=  n 


T4:  n:=  n-1 


T5:  n  >  0 


Petri  net  for  the  computation  of  the  factorial 

Let  us  start  with  a  very  simple  computation— the  evaluation  of  factorialin).  where  n 
is  a  nonzero  integer.  Our  first  example  of  a  Petri  net  is  for  this  computation,  and  it  is 
shown  with  its  initial  marking.  Transitions  represent  steps  in  the  computation,  and  the 
movement  of  tokens  between  places  sees  to  it  that  these  computational  steps  are  properly 
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sequenced.  If  a  transition  is  annotated  with  a  predicate,  as  T5  and  T6  are  in  the  figure,  then 
the  normal  firing  rule  is  augmented  with  the  requirement  that  the  predicate  be  true.  Sup¬ 
pose  n  =  0.  Then  T1  and  T6  can  fire.  When  they  do.  tokens  move  into  P2  and  P8,  and  the 
process  stops  with  /  =  1  because  no  further  firings  can  take  place.  On  the  other  hand,  if  n  is 
greater  than  zero,  then  T1  fires  as  before,  but  now  it  is  T5  that  fires  at  the  lower  end.  This 
moves  a  token  into  P7.  and  T3  can  fire.  Firing  of  T3  moves  tokens  into  P4  and  P5,  so  that 
T2  and  T4  can  fire  next.  Note  the  parallelism:  P2.  T2,  P3.  and  P4  represent  one  process,  the 
building  up  of  the  factorial  by  the  multiplication  at  T2:  P5,  T4,  P6.  T5.  and  P7  represent 
another  process,  the  adjustment  of  n  at  T4.  The  point  of  contact  of  the  two  processes  is  T3, 
where  the  current  value  of  n  is  assigned  to  k.  An  alternative  would  be  to  pass  the  current 
value  of  n  in  a  message  from  process  to  process  at  T3.  In  any  case,  the  design  of  the  net¬ 
work  and  the  initial  marking  make  sure  that  the  two  processes  do  not  get  out  of  step. 


Petri  net  representation  of  mutual  exclusion 

Next  we  consider  two  processes  that  are  to  have  access  to  a  particular  resource,  but 
never  both  at  the  same  time.  This  is  known  as  mutual  exclusion.  In  the  figure,  let  a  token  in 
P2  represent  access  to  the  resource  by  process  A,  and  a  token  in  P4  access  by  process  B. 
Under  the  marking  as  shown,  both  T1  and  T3  are  enabled  to  fire.  Suppose  T1  fires.  This 
removes  tokens  from  PI  and  P3  and  places  a  token  in  P2.  While  this  token  remains  in  P2. 
transition  T3  cannot  fire,  i.e..  while  there  is  a  token  in  P2  there  cannot  be  a  token  in  P4,  and 
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vice  versa. 


In  the  specification  of  systems  that  are  primarily  control  systems  a  Petri  net  may  be 
used  from  the  very  start  to  define  the  structure  of  the  system.  We  show  a  net  that 
represents  a  manufacturing  system  consisting  of  one  producer  and  two  consumers.  The 
"producer"  .4  consists  of  places  PI.  P2.  and  P3.  and  transitions  Tl  and  T2  “Consumers"  B 
and  C  ha •.  e  the  same  configuration  as  the  producer.  For  example,  the  producer  could  assem¬ 
ble  toasters,  and  the  consumers  package  the  toasters.  The  producer  generates  at  PI  objects, 
which  are  represented  by  tokens.  Firing  of  T2  sends  one  token  to  P2  to  keep  the  process 
going,  and  another,  w'hich  represents  the  generated  object,  to  P3.  The  generation  of  an 
object  is  triggered  by  the  placing  of  a  token  in  D.P1  (an  external  input),  and  the  objects 
finally  go  to  place  D.P2.  which  acts  as  a  buffer.  Tokens  are  taken  off  D.P2  by  either  B.Tl  or 
C.T1.  the  entry  points  to  the  consumer  processes.  The  actual  processing  occurs  at  B.Pl  and 
C.P1.  and  the  finished  goods  end  up  in  D.P3.  via  B.P3  or  C.P3.  The  initial  marking  consists 
of  one  token  each  at  A.P2.  B.P2.  and  C.P2. 

The  translation  of  the  Petri  net  into  SF  is  schematic  in  that  we  ignore  anything  to  do 
with  with  the  data  base,  i.e.,  preconditions,  setconditions.  and  mapeonditions.  It  must  be 
understood  that  in  SF  the  time  at  which  a  transition  fires  is  explicitly  defined,  and  that  an 
event  triggered  by  a  transition  only  lakes  place  if  its  preconditions  are  satisfied.  We  let 
each  of  processes  .4.  B.  C  of  the  figure  be  an  SF  segment.  Consider  the  producer  process, 
where  we  assume  that  the  actual  time  to  produce  an  object  is  20  minutes.  The  schematic 
specification  of  segment  .4  now'  follows.  There  signal  T\  'start  is  set  outside  the  segment, 
and  signal  Process  complete  triggers  an  event  outside  of  segment  A.  Event  A.P3  (and  tran¬ 
sition  D.T1  appear  superfluous),  but  they  are  needed  to  support  an  SF  convention  that  no 
event  may  be  initiated  directly  from  another  segment.  This  contributes  to  the  ease  of 
developing  segments  independently  of  each  other.  Flence  we  need  a  transition  within  seg¬ 
ment  D  to  initiate  D.P2  (transition  D.Tl).  and  an  event  in  A  that  is  to  trigger  this  transition 
(event  A.P3). 
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SEGMENT  A: 


IMPORTED  SIGNALS  T 1  start  ; 

EXPORTED  SIGN  ALS  Process  'complete  : 

INTFRNAl  EVENT  Pi  : 

SIGCONDITIONS-  (T2  'trigger  )ON: 

ENDEVENT. 

INTERNAL  EVENT  P2  : 

SIGCONDITIONS-  (7T  ‘ trigger  )ON; 

ENDEVENT: 

INTERNAL  EVENT  P3  : 

SIGCONDITIONS—  ( Process  complete  )ON; 

ENDEVENT: 

TRANSACTION  T\  : 

@  (7"  Vow  ):  ANDCONtn  "start  )OFF.  ON(n  ‘ trigger  )OFF):  PI  : 

ENDTRANS  ACTION: 

TRANSACTION  T2  : 

@  (T~. Delay  (20,  7'. Now  )):  ON(P2  ” trigger  )OFF:  P2  :  P3  ; 

ENDTR  ANSACTION ; 

F.NDSEGMENT: 

The  delay  of  20  minutes  represents  the  lime  required  to  produce  an  object.  If  signals 
are  combined  by  an  AND,  they  must  both  be  in  the  ON-state  for  anything  to  happen,  e.g..  if 
T\  'start  alone  is  on  when  T\  is  processed,  then  7T  'start  does  not  get  turned  off.  The 
specifications  of  segments  B  and  C  have  exactly  the  same  form  as  that  of  A.  The  only 
difference  is  in  transaction  T2  :  this  transaction  is  likely  to  have  shorter  delays  in  B  and  C. 
The  modularization  of  the  system  has  been  carried  out  in  such  a  way  that  the  specifications 
of  segments  A.  B.  and  C  would  not  have  to  be  changed  if  they  were  to  be  used  in  some 
other  context.  Here  they  are  coordinated  by  segment  D.  and  a  schematic  specification  of  D 
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now  follows. 


SEGMENT  D: 

IMPORTED  SIGNALS  A. Process  complete  .  B. Process' complete  .  C. Process  ~ complete  ; 
EXPORTED  SIGNALS  A.T\  start  ,  B.T1  'start  ,  C.T\  star:  .  Ti  'inventory  - 
EVENT  P\  ; 

SIGCONDITIONS—  (A.T\  'start  )ADD; 

ENDEVENT; 

INTERNAL  EVENT  PI  ; 

SIGCONDITION’S-  AND(0FF(5.n  'start  )ON.  ON (P2  '  inventory  )OFF); 

AND(OFF(C.n  'start  )ON,  0\{P2  'inventory  )OFF); 

ENDEVENT: 

INTERNAL  EVENT  P3  : 

ENDEVENT: 

TRANSACTION  T\  : 

@  (T'.jXow  ):  BLOCK 

ON  (.A.  Proce  ss  complete  )OFF:  {PI  inventory  )ADD; 

0R(0FF(5.71  'start ).  OFF(C.n  'start  )):  PI  : 

ENDBLOCK; 

ENDTRANSACTION: 

TRANSACTION  T2  : 

@  (T  .Now):  ON  {B. Process  complete)  OFF:  (P3  inventory  )ADD: 
ENDTRANSACTION: 

TRANSACTION  T3  : 

@(T  .Now):  ON(C.  Process  'complete  )OFF:  (P3 'inventory  )  ADD: 
ENDTRANSACTION; 

ENDSEGMENT: 

AT  1  start.  PI  inventory,  and  P3  inventory  differ  from  other  signals.  Thev  are 
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counters  rather  than  flags.  An  ADD  operation  increments  a  count,  and  also  identifies  a  sig¬ 
nal  as  a  counter.  In  this  context  ON '{Counter)  is  true  if  Counter  is  non-zero,  and 
{Counter) OFF  decrements  Counter.  The  computation  associated  with  the  processing  of  a  sig¬ 
nal,  such  as  ON (P2  inveruor\  )OFF.  must  be  atomic.  Otherwise  both  the  B  T 1  ~ start  and 


C.7T  start  of  our  example  could  get  set  when  there  is  only  one  item  in  the  inventory. 
Event  D.P3  is  left  totally  unspecified.  Another  process  could  be  fed  by  it.  such  as  the  dis¬ 
tribution  of  finished  products  to  sales  points. 


A  problem  that  arises  quite  frequently  has  to  do  with  the  ISA.  Suppose  that  referees 
form  a  subset  of  persons  (asserted  by  means  of  an  ISA),  individual  x  is  being  selected  as  a 
referee,  but  individual  x  is  not  in  the  set  of  persons  P.  One  approach  is  to  test  for  member¬ 
ship  of  x  in  P.  and  simply  not  to  proceed  with  the  referee  selection  event  if  the  test  is  not 
satisfied. 


A  better  solution  is  to  make  referee  selection  a  two-stage  process.  First  test  for 
membership  in  P.  If  the  test  is  passed,  proceed  with  referee  selection  (as  an  internal  event). 
Otherwise  raise  a  signal  that  prompts  an  event  in  the  parent  segment  to  add  x  to  P.  This 
event  raises  a  signal  that  causes  x  to  become  a  referee.  The  Petri  net  of  this  paradigm: 


section  of 
parent 


segment 
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SPECIFICATION  OF  THE  ELEVATOR 


The  requirements  statement  for  the  problem  asks  for  the  specification  of  a  system  of 
elevators.  Initially  we  hoped  to  develop  two  segments— an  elevator  segment,  and  a 
dispatcher  segment  that  was  to  decide  which  elevator  was  to  respond  t<>  an  outside  call  for 
service  and  was  to  move  idle  elevators  to  strategically  picked  holding  floors.  But  the 
"specification"  of  the  dispatcher  then  encroaches  on  design.  An  algorithm  has  to  be  selected 
that  is  based  on  queueing  theory  and  scheduling  theory,  and  the  algorithm  may  have  to  be 
tuned  on  the  basis  of  simulation  experiments.  We  maintain  is  that  a  specification  should  be 
prealgorithmic.  but  this  means  that  the  dispatcher  cannot  be  specified.  Of  course,  il  the 
requirements  actually  propose  an  algorithm,  then  the  specification  should  reflect  the  charac¬ 
teristics  of  the  algorithm.  This  was  the  case  with  the  two-way  merge.  In  the  present 
instance,  if  an  algorithm  had  been  supplied  for  the  dispatcher,  then  we  could  have  written  a 
specification,  but  we  could  not  be  expected  to  devise  the  algorithm. 

As  regards  the  elevator  segment,  we  realized  from  the  very  start  that  we  should  con¬ 
sider  state  transitions.  However,  at  first  we  had  only  the  states  idle,  halt .  and  move.  It  did 
not  take  long  to  realize  that  the  halt  state  could  not  cope  with  emergency  stops,  and  a 
separate  stop  state  was  added.  However,  a  whole  day  of  false  starts  was  wasted  before  the 
realization  that  states  move.  hall,  and  stop  had  to  be  split  on  the  basis  of  whether  the  eleva¬ 
tor  movement  is  up  or  down. 

This  put  us  in  a  position  to  define  external  events,  but  when  it  came  to  the  linking  of 
events  into  processes,  and  the  definition  of  internal  events  (eight  of  a  total  of  fourteen),  the 
interrelation  of  events  and  transactions  was  becoming  so  tangled  that  we  had  no  overview 
of  the  total  system.  The  Petri  net  representation  showed  below  established  the  overview. 
In  the  diagram  of  the  net  we  use  abbreviations,  as  listed  in  the  table  on  the  page  that  fol¬ 
lows  the  diagram  of  the  net. 
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AE  - 

Activate' elevator 

AtoA- 

Add  to  agenda 

FH  - 

Enter  halt 

IE  - 

Idle  elevator 

Init  - 

Initialize  elevator 

Ml  - 

Move  idle 

NFS  - 

Next  floor' sensor 

OD- 

Open  door 

PB  - 

Press  button 

PH  - 

/V,  >cess  halt 

PS- 

Passing  sensor 

RE  - 

Reactivate  elevator 

SIM  - 

Set  in  motion 

Stop  - 

Stop  elevator 

uc- 

Update  clock 

As  before,  places  stand  for  events,  transitions  for  transactions.  The  transitions  carry  labels 
that  refer  to  the  signals  processed  by  the  transactions  that  these  transitions  represent.  The 
broader  bars  indicate  transactions  that  are  initiated  from  the  outside.  The  five  place  sym¬ 
bols  that  are  not  part  of  the  main  net  represent  events  that  do  not  directly  cause  other 
events;  one  of  these,  event  Add' to' agenda,  is  initiated  by  the  dispatcher. 

SPECIFICATION  OF  DATA  TRANSFORMERS 

Data  flow  diagrams  can  assist  in  the  specification  of  data  transformers.  These 
diagrams  form  the  basis  of  the  "structured  analysis"  approach  to  development  of  systems. 
A  data  flow  diagram  is  built  up  of  components  of  four  types:  ( 1 )  Sources  and  sinks,  which 
are  external  agencies  that  send  data  into  the  system  or  receive  data  from  the  system.  They 
are  represented  by  boxes.  (2)  Processes,  which  are  represented  by  circles.  (3)  Files  or  data 
bases,  represented  by  two  parallel  lines.  (4)  Data  flows,  which  are  represented  by  arcs  link¬ 
ing  pairs  of  objects  of  the  first  three  types. 

An  information-control  system  is  based  on  a  centralized  data  base,  and  all  "flow" 
relates  just  to  the  updating  and  interrogation  of  this  data  base.  Consequently  data  flow 
diagrams  are  of  little  use  in  the  specification  of  information-control  systems.  But  the  situa¬ 
tion  is  quite  different  with  data  transformers.  Here  actual  data  objects  are  moved  from 
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process  to  process,  and  each  process  carries  out  some  transformation  of  these  objects. 

Our  example  is  the  data  flow  diagram  of  a  spelling  checker.  A  text  file  enters  the  sys¬ 
tem  and  the  text  is  split  into  words  at  node  SW.  The  word  list  that  is  the  result  of  this 
operation  is  sorted,  and  process  RD  removes  duplicates  from  the  sorted  list.  At  SD  (Sub¬ 
tract  Dictionary)  this  reduced  list  is  compared  against  a  stored  dictionary,  and  words  not 
found  in  the  dictionary  are  presented  to  the  user. 


Dictionary 


Data  flow  in  a  spelling  checker 

Actually,  with  this  diagram  we  have  moved  well  out  of  specifications  and  into 
software  design.  The  indication  that  the  word  list  produced  from  the- text  file  should  be 
sorted,  and  duplicates  removed  from  it.  is  the  selection  of  an  algorithm.  A  specification 
should  not  go  that  far.  Instead,  for  a  specification  we  should  regard  the  word  list  (call  it 
W)  and  the  dictionary  (D)  as  sets,  and  the  errata  list  is  then  the  set  difference  W-D.  How 
the  set  difference  is  obtained  should  be  of  no  concern  to  the  writer  of  the  specifications. 
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Support  Materials 


Formal  Specification  of  Software 


Formal  Specification  Courses 


Alts  Berztiss 
University  of  Pittsburgh 


Details  of  course  organization  are  described.  Examples  are  drawn  from  experiences  at  the  University  of  Pitts¬ 
burgh.  Suggestions  for  exercises  and  projects  are  included. 


SEI-SM-8-1.0 


Draft  For  Public  Review 
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FORMAL  SPECIFICATION  COURSES 


COURSE  OUTLINES 

These  outlines  relate  to  courses  dealing  with  formal  specification  offered  by  the 
Department  of  Computer  Science.  University  of  Pittsburgh.  .Course  CS135  is  taken  by 
undergraduates,  usually  in  their  senior  year.  The  prerequisite  structure  ensures  that  they 
have  completed  at  least  five  computer  science  courses.  CS231A  is  a  graduate  course,  where 
the  only  prerequisite  is  admission  to  graduate  study  in  computer  science.  At  the  University 
of  Pittsburgh  this  essentially  means  that  the  student  has  an  undergraduate  major  in  com¬ 
puter  science.  Each  lecture  lasts  80  minutes. 


CS135-  SOFTWARE  SYSTEMS  DESIGN  Fall  1987/8 


1  (Sep.  2): 

2  (Sep.  9): 

3  (Sep.  14 ): 

4  (Sep. 16): 

5  (Sep. 21): 

6  (Sep. 23): 

7  (Sep. 28): 

8  (Sep. 30): 

9  (Oct.  5): 

10  (Oct.  7): 

11  (Oct.12) 

12  (Oct.  14) 

13  (Oct.  19) 


Introduction  to  course 
Software  life  cycle 
Componentsof  computations 
Principles  of  modularization 
The  SF  (set-function)  methodology 
Specification:  Boat  hire 
Specification:  A  library  system 
Initial  discussion  of  the  term  project 
Petri  nets  I 
Petri  nets  II 

Specification:  An  elevator 
Specification:  A  text  formatter 
Testing  of  specifications 


(Oct. 21):  MIDTERM  EXAMINATION  (open  book) 


14  (Oct. 26): 

15  (Oct. 28): 

16  (Nov.  2): 
1  7  (Nov.  4): 

18  (Nov.  9): 

19  (Nov. 11): 

20  (Nov. 16): 


Site-related  aspects  of  the  SF  methodology 

Property  inheritance  and  knowledge  representation 

Review  of  the  SF  methodology 

More  on  testing 

More  on  the  project 

Errors,  uncertainties,  exceptions 

Entity-relationship  model 
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:i 

(Nc.  18): 

Abstract  data  types  ! 

( No  •  .23): 

Abstract  data  types  II 

.Nr.  30!. 

Data  types  and  generators 

2  j 

(Dec.  2): 

Programming  with  generators 

De;  7): 

From  specifications  to  software  I 

Dr..  9): 

From  specifications  to  software  11 

Dec. 17):  FINAL  EXAMINATION  (open  book)  10:00-11:20 


CS231  A-  SOFTW  ARE  ENGINEERING:  SPECIFICATION  AND  DESIGN 


1  (Jan  7): 

2  (Jan  12): 

3  (Jan  14): 
■i  1  Jar.  19): 
'  Ja-  21): 

6  t. Jar.  26): 

7  (Jan.28): 

8  (Feb.  2): 
-(Fe*  4): 

I  »(Fer  9): 

II  (Feb.  11) 

12  (Feb.16) 

13  (Feb. 18) 

14  (Feb.23) 

15  (Feb. 25) 

16  (Mar.  1) 


Introduction  to  software  engineering 
Software  life  cycle 
Components  of  computations 
Abstract  data  types:  introduction 
Hierarchies  and  modules 
The  SF  (set-function)  methodology 
Specification:  bank  accounts 
Specification:  a  library  system 
Discussion  of  the  term  project 
Petri  nets:  introduction 
Petri  nets  and  SF  specification 
Petri  nets  in  process  analysis 
Specification:  an  elevator 
Testing  of  specifications 
Abstract  data  types  I 
Abstract  data  types  II 


(Mar.  3):  MIDTERM  EXAMINATION  (open  book) 


17  (.Mar. 15) 
IS  (Mar.  17) 

19  (Mar. 22) 

20  (Mar. 24) 

21  (Mar. 29) 

22  (Mar. 31 ) 

23  (Apr.  5): 

24  (Apr.  7): 

25  (Apr.  12) 

26  (Apr.  14) 

27  (Apr. 19) 

28  (Apr.21) 

29  (Apr. 26): 


Review  of  the  SF  methodology 

Specifications:  a  text  formatter  and  two-way  merge 

Data  types  and  generators 

Programming  with  generators 

The  Larch  approach  to  specifications 

Larch  and  CLL 

The  Z  specification  language 

Z  and  specification  of  processes 

The  PAISLey  and  MSG. 84  methodologies 

The  Vienna  Development  Method  in  specification 

Sites  and  knowledge  representation  in  SF 

From  specifications  to  software  by  transformations:  I 

From  specifications  to  software  by  transformations  II 


(Apr. 28):  FINAL  EXAMINATION  (open  book) 


Winter  1987/8 
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PRACTICAL  WORK 


A  course  dealing  with  specification  should  be  centered  on  a  major  group  project,  but 
several  individual  exercises  are  an  essential  preliminary  to  the  group  project.  First,  this 
allows  the  instructor  to  find  out  which  specification  principles  and  methodologies  the 
instructor  had  not  fully  explained.  Second,  misconceptions  by  individual  students  can  be 
corrected.  Third,  the  instructor  comes  to  understand  the  capabilities  of  the  students.  On  an 
individual  basis  this  helps  during  the  selection  of  teams  for  the  group  project.  More 
broadly,  the  level  of  difficulty  of  a  project  can  be  matched  to  the  experience  of  the  class. 

As  regards  the  group  project,  we  have  generally  started  out  with  four  to  five  students 
to  a  specification  team.  A  smaller  group  may  become  ineffective  if  a  member  drops  out  or 
fails  to  contribute  adequately,  and  the  duration  of  projects  is  too  short  to  justify  larger 
groups.  Our  standard  practice  has  been  to  assign  students  to  groups  in  alphabetical  order. 
However,  if  chance  puts  too  many  weaker  students  in  a  group,  some  switching  should  be 
done.  Otherwise  the  group  may  not  get  going.  For  greater  realism,  we  intend  to  experiment 
with  the  transfer  of  stronger  students  from  one  group  to  another  (that  works  on  a  different 
project)  halfway  through  the  exercise. 

Our  grading  scheme  has  been  to  derive  50 %  of  the  total  grade  from  examinations  and 
50%  from  individual  assignments  and  the  project,  but  at  times  we  have  dispensed  with  the 
midterm  examination,  in  which  case  the  project  has  carried  50% .  assignments  25%,  final 
examination  25%. 

A  project  is  first  given  an  overall  grade,  for  example  along  the  lines 

Quality  of  the  specification  -  20  points 
Documentation  -  10  points 
Project  log  -  5  points 
Validation  (walkthroughs)  -  10  points 
General  presentation  -  5  points 

The  overall  grade  may  then  be  reduced  (sometimes  raised)  for  individual  members  of  the 
team  according  to  three  criteria.  First,  each  student  is  required  to  do  a  confidential  rating  of 
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all  members  of  his  or  her  team  by  indicating  the  percentage  of  the  total  effort  contributed 
by  each  individual.  Second,  each  group  keeps  a  project  log.  The  log  provides  a  record  of 
attendance  at  meetings  and  of  individual  assignments.  Third,  the  quality  of  the  work 
assigned  to  an  individual  is  compared  to  the  quality  of  the  work  by  others  in  the  group. 
However,  group  interaction  tends  to  smooth  out  differences  in  quality  of  a  specification,  i.e.. 
quality  tends  to  be  uniform  across  an  entire  specification  document.  Indeed,  students  work¬ 
ing  as  a  group  influence  each  other  in  such  a  way  that  all  members  contribute  equally,  with 
the  weaker  students  investing  more  time  in  the  project.  The  exceptions  are  few.  and  the  log 
and  the  student  ratings  identify  them  very  well  (a  lowered  score  for  just  six  of  42  students 
is  typical). 


A  LOGBOOK:  ELEVATOR  SPECIFICATION 


Meeting  #  1 
Feb.  2,  1987 
6:30  Hillman  Lib. 

Absent:  Nobody 

Accomplished:  Group  members  simply  got  acquainted  and  discussed 

possible  meeting  times.  Monday  evenings  were  discovered  to  be 
the  best  time  to  meet,  and  it  was  agreed  upon  by  all  members. 


Meeting  #  2 
Feb  19,  1987 
6:00  Hillman  Lib. 

Absent:  Nobody 

Accomplished:  Basic  setup  of  functional  requirements  was  es¬ 

tablished.  It  was  decided  that  two  segments  would  be  required; 
an  operator,  and  a  dispatcher.  The  imported  types  and  signals 
were  agreed  upon  and  written.  Each  menber  was  then  assigned 
specific  events  and  everybody  agreed  to  write  one  version  of  the 
event  Next  Move. 


Channarasappa :  Add_Call_To_Agenda 

Move_Elevator 

Correa:  Delete_Floor_From_Agenda 

Ha 1 t_A  t_A_F 1 o  o  r 

Eaton:  Move_Elevator 

Stop_At_A_Floor 

Fetsko :  Add_Select_Floor_To_Agenda 

Emergency_S  top 


Meeting  #  3 
Feb.  23,  1987 
6:00  Hillman  Lib. 


Absent:  Nobody 

Accomplished:  Basic  structure  of  operator  and  dispatcher  put 

together.  The  assigned  events  were  reworked  at  meeting  so  they 
all  used  similar  terms  and  notations.  The  event  Next_Move  was 
assigned  to  all  group  members  again  since  no  workable  solution 
could  be  found.  The  two  main  types:  Elevator  and  Agenda,  were 
then  written  and  agreed  upon. 


Meeting  #  4 
Feb.  24,  1987 
3:30  Alumni  Lib. 

Absent:  Nobody 

Accomplished:  As  a  group  effort,  an  ASM  chart  was  setup  for  the 

event  Next_Move.  From  this  chart,  we  were  able  to  find  the  signal 
and  map  conditions  necessary  to  have  a  complete  working  version. 
Once  written,  The  event  was  vigorously  tested  and  subsequently 
found  to  be  satisfactory. 
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•Meeting  #  5 

March  2,  1987 
6:00  Hillman  Lib. 

Absent:  Nobody 

Accomplished:  All  the  events  were  tied  together  after  some 

editions  to  them.  The  functions  of  each  segment  type  were 
then  written.  And  finally,  a  rough  version  of  the  functional 
requirements  was  completed.  Each  member  was  then  assigned  to 
type  in  his  or  her  events  into  one  account  or  file. 


Meeting  #  6 
March  4,  1987 
6:00  Hillman  Lib. 


Absent:  Nobody 


Accomplished:  This  meeting  was  more  or  less  an  initial  debugging 

session.  As  a  result,  errors  were  detected  in  many  areas  of  the 
requirements  and  fixed  by  the  group. 


Errors  detected  in: 

Dispatcher : 

Type  Agenda: 

Add_Select_Floor_To_Agenda : 
Next  Move: 


imported  signals  and  types 

functions 

mapconditions 

mapcondi tions 


Operator : 

Type  Elevator: 
Move_Elevator : 
Halt  At  A  Floor 


imported  signals 
functions 
map  conditions 
signal  conditions 
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Meeting  #  7 
March  9,  1987 
6:00  Forbes  Quad. 

Absent:  Nobody 

Accomplished:  A  format  for  the  documentation  was  setup  and 

agreed  upon.  Each  member  was  then  assigned  to  write  an  equal 
portion  of  it  and  type  it  in. 

Channarasappa:  Segment  Operator 

Type  Elevator 
Event  Stop_At_A_Floor 
Ha 1 t_A  t_A_F 1 o  o  r 

Correa:  Segment  Dispatcher 

Event  Add_Select_Floor_To_Agenda 
Event  Move_Elevator 
Event  Emergency_stop 

Eaton:  Event  Add_Call_To_Agenda 

Event  Delete_Floor_From_Agenda 
Event  Stop_Release 

Fetsko:  Introduction 

Event  Next_Move 
Type  Agenda 


Meeting  #  8 
March  16,  1987 
6:00  Hillman  Lib. 

Absent:  Nobody 

Accomplished:  Material  was  passed  out  for  walkthrough.  A  date, 

time,  and  location  was  setup  at  the  Hillman  Library  on  March  18, 
1987  at  4:00  PM. 
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Meeting  #  9 
March  18,  1987 
4:00  Hillman  Lib. 

Absent:  Nobody 

Accomplished:  The  walkthrough.  Errors  were  detected  in  the  event 
Emergency_Stop  which  required  the  addition  of  the  event  E_Stop. 
Errors  were  also  detected  in  the  segment  operator. 

Note:  These  errors  were  not  fixed  until  the  walkthrough  was 

completed. 


Meeting  #  10 
March  21,  1987 
6:00  Hillman  Lib. 

Absent:  Nobody 

Accomplished:  The  final  version  was  reviewed  and  accepted  by  all 

the  group  members.  PROJECT  COMPLETE! 


FROM  OTHER  LOGBOOKS 

Specification  groups  working  on  a  student  registration  system  were  encouraged  to 
interview  university  staff  actually  concerned  with  registration  before  requirements  were 
defined.  Only  one  member  of  the  team  was  to  meet  with  each  official.  Members  of  one 
group  interviewed  three  university  officials:  the  Director  of  the  Undergraduate  Programs 
Office  in  the  Department  of  Computer  Science  (4  pages  in  the  log),  an  official  in  Student 
Business  Services  (another  4  pages  in  the  log),  and  a  student  advisor  in  the  College  of  Gen¬ 
eral  Studies  (2  pages  in  the  log).  This  group  maintained  three  logs:  a  chronological  log,  a 
walkthrough  log.  and  a  communications  log.  The  latter  contains  the  detailed  accounts  of 
the  information  elicited  in  the  interviews. 

One  group  devised  a  form  that  was  used  at  meetings  of  the  group.  The  set  of  forms 
for  all  meetings  was  their  log.  A  sample  from  this  log  is  the  next  page. 
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LOG  for  Group  7  Page  :  K 


Work  completed  &  by  Whom  : 


!\oss  Socc  v^ccAiqa  bu  ~^crfM  OK<v, 


LXERCISfc'S  AND  PROJECTS 


Small  SF  specifications .  The  first  exercise  can  be  the  grade  record  for  a  class.  Next  is 
an  appointments  calendar  with  reminders.  From  this  one  can  advance  to  an  automobile 
maintenance  data  base  that  keeps  track  of  all  maintenance  activities  and  reminds  the  driver 
cl  periodic  checks.  At  about  the  same  level  of  difficulty  is  a  subscription  system  that 
accepts  subscriptions  for  a  journal,  determines  when  renewal  notices  and  follow-up  notices 
are  to  be  sent  out.  and  takes  care  of  explicit  and  implicit  cancellations. 

Extension  of  the  elevator  specification.  The  elevator  specification  given  as  an  example 
of  the  use  of  SF  can  be  refined.  Thus,  the  case  can  be  examined  in  which  the  agenda  of  an 
elevator  is  empty,  but  nullweight  returns  false.  This  sensor  can  actually  be  replaced  by  a 
real-valued  sensor  that  indicates  the  weight  of  the  contents  of  the  elevator.  Overloading  of 
the  elevator  can  then  also  be  dealt  with.  A  further  extension  should  be  provided  to  take 
care  of  recovery  of  the  ele\ator  from  a  power  failure.  Extend  the  given  specification,  but 
beware  of  "goldplating".  namely  a  situation  in  which  the  system  becomes  too  elaborate.  For 
example,  a  person  who  has  pressed  a  wrong  button  could  wish  for  a  means  of  cancelling 
this  action.  However,  pressing  all  buttons  is  recommended  as  a  countermeasure  to  being 
attacked  on  an  elevator,  and  a  cancelling  feature  would  reduce  the  effectiveness  of  this 
measure. 

Formal-wear-hire  and  dry-cleaning  establishment.  An  establishment  consists  of  a 
formal-wear-hire  section  and  a  laundry  and  dry-cleaning  section.  The  formal-wear-hire 
section  hires  out  bridal  gowns,  ball  gowns,  tuxedos,  and  similar  garments.  The  hiring 
charge  for  each  item  is  composed  of  a  fixed  charge  and  a  variable  charge  determined  by  the 
length  of  the  period  of  hire.  The  total  variable  charge  for  a  hire  transaction,  which  may 
involve  several  garments,  depends  also  on  the  total  fixed  charge— the  variable  charge  is 
reduced  by  a  percentage  proportional  to  the  amount  of  the  total  fixed  charge.  All  garments 
go  to  the  laundry  and  dry-cleaning  section  on  return,  but  this  section  also  launders  and 
dry-cleans  for  the  general  public.  Develop  an  SF  specification  of  this  establishment.  In 
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particular,  determine  how  much  (if  anything)  this  specification  has  in  common  with  the 
boat-hire  specification,  and  devise  an  approach  that  takes  advantage  of  any  commonality, 
i.e..  examine  to  what  extent  components  of  an  SF  specification  can  be  made  reusable. 


Traffic  lights.  Traffic  lights  X  go  through  a  sequence  ....  green,  amber,  red.  green . 

The  duration  of  the  amber  period  is  fixed,  but  the  durations  of  the  green  and  red  periods  are 
adjustable  parameters.  Lights  V  are  driven  by  lights  X.  The  duration  of  the  amber  period 
is  the  same  as  for  lights  X,  and  there  is  a  fixed  overlap  period  at  which  both  sets  of  lights 
show  red.  Write  an  SF  specification  for  this  system.  Suppose  lights  Z  are  no\x  installed. 
They  are  to  be  driven  by  lights  X  and  are  to  be  synchronized  with  them  so  that  the  green, 
amber,  and  red  periods  have  the  same  durations  for  both  lights,  but  the  sequence  for  Z  lags 
behind  the  sequence  for  X  by  some  adjustable  time  interval.  Does  this  modification  need  to 
cause  any  changes  to  the  segment  that  controls  lights  X? 


XX  z  z 

Y  _ 


n; 

V  R 

m 

\  R 

. 

Automobile  cruise  control.  This  system  is  to  maintain  an  automobile  at  a  fixed  cruising 
speed.  A  mechanism  monitors  the  current  speed  of  the  car  and  adjusts  the  throttle  setting 
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whenever  the  current  speed  has  deviated  too  far  from  the  selected  cruising  speed.  There  are 
three  switches.  The  cruise  control  on/ off  switch  engages  or  disengages  the  system.  Cruise 
control  may  only  be  engaged  when  the  engine  is  on.  and  it  automatically  disengages  when 
the  engine  goes  off.  When  the  system  is  engaged,  a  cruising  speed  is  selected  by  bringing  the 
car  to  this  speed  and  pressing  a  "select"  button.  Application  of  brakes  cuts  out  cruise  con¬ 
trol.  and  the  speed  has  to  be  controlled  manually.  Now ,  if  the  "select"  button  is  pressed,  the 
actual  current  speed  becomes  the  new  cruise  speed,  but  if  a  "resume"  button  is  pressed,  then 
the  system  reverts  to  the  cruising  speed  in  effect  before  braking.  Acceleration  also  overrides 
cruise  control,  but  in  this  case  resumption  of  the  cruising  speed  is  automatic.  However, 
"select"  can  again  be  used  to  select  a  new  cruising  speed.  Write  a  formal  specification  for 
this  system. 

Coin-operated  luggage  lockers.  The  basic  usage  of  the  lockers  is  as  follows:  (l)  luggage 
is  deposited  in  an  unoccupied  locker,  and  the  door  of  the  locker  is  closed:  (2)  an  appropriate 
payment  is  made,  the  door  is  locked,  and  the  user  gets  a  key;  (3)  the  key  unlocks  the  locker 
door  at  any  time  within  the  next  24  hours,  say.  and  the  locker  then  reverts  to  unoccupied 
status.  Many  variants  of  this  basic  pattern  exist.  For  example,  in  some  French  railway  sta¬ 
tions  lockers  come  in  sets  of  six.  each  set  being  provided  with  just  one  control  mechanism. 
After  the  luggage  has  been  deposited  in  an  unoccupied  locker  and  the  door  closed,  turning  of 
the  door  handle  causes  the  mechanism  to  display  the  amount  of  money  to  be  deposited.  As 
coins  are  dropped  in.  the  display  show's  how  much  remains  to  be  paid.  Hire  is  for  48  hours, 
and  there  is  a  return  of  change  in  case  of  overpayment.  On  receipt  of  payment  the  mechan¬ 
ism  locks  the  door,  prints  the  identifier  of  the  locker  and  a  numerical  lock  code  on  a  slip  of 
paper,  and  outputs  this  slip  of  paper.  The  door  is  unlocked  by  input  of  the  lock  code  from 
a  small  keyboard  that  is  part  of  the  control  mechanism.  Note  that  during  the  time  between 
the  turning  of  the  door  handle  and  receipt  of  the  lock  code  it  should  not  be  possible  to  turn 
the  other  five  door  handles.  Hence  it  is  essential  that  a  transaction  be  terminated  whenever 
this  time  interval  exceeds  a  limit.  Write  a  specification  for  this  system.  Write  it  in  such  a 
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way  that  the  system  can  be  easily  convened  to  variable  hiring  times.  Under  this  variant, 
as  coins  are  dropped  in.  the  display  shows  the  length  of  time  that  the  payment  has  bought 
this  far. 

Student  registration.  An  SF  specification  of  a  student  registration  system  is  an  open- 
ended  project.  It  can  be  made  as  modest  or  as  elaborate  as  time  permits.  The  students 
should  themselves  decide  what  to  include  in  their  systems. 

Merge  of  sorted  lists.  Write  a  specification  for  a  data  transformer  that  generates  a 
sorted  list  from  an  input  of  two  sorted  lists. 

The  n-queens  problem.  Consider  the  problem  of  placing  n  queens  on  an  n  x  n  chess 
board  so  that  they  do  not  attack  each  other.  The  solution  is  a  Boolean  function  Q. 

Q :  l..n  X  l..n  — »  Boolean. 

such  that  Q(i,  j )  is  true  when  square  (t.  j )  holds  a  queen,  and  Q{i.  j)  is  false  when  square  (i. 
j)  does  not  hold  a  queen.  The  specification  is  to  be  a  predicate  N'queensin )  that  is  true  for 
every  Q  that  solves  the  problem  and  false  otherwise.  (The  implementation  consists  of 
finding  actual  functions  Q  that  make  AT  queens  true.) 

Solution: 

N  queens  (n  )  = 

Allop  (A :  ( 

Allop  (V;  {Q(i .  j  ) 

A  Allop  (A;  {not((7  {s  .  j  ))  I  1^5  ^i-1  V  i+l^j  ^n|) 

A  AllopiA:  {not((?(t  .  t  ))  I  1  <r  —  1  V  y+l^r^-nl) 

A  Allop  (A;  +t=i+/  V  j  —  t  —i  —  j  — *  not(£>  U  ,  t  )) 

I  (l^i^i-1  V  i+Kj  ^n)A  (K;  ^/-l  V  y'  +  l^r^n)}) 

I  1  ^  j  ^ n  }) 

I  1  }); 

A  spelling  checker.  Using  the  discussion  of  a  spelling  checker  given  on  p.fi4  as  a  guide, 
develop  predicative  specifications  of  the  components  of  the  spelling  checker. 
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Additional  specification  poblems.  Three  interesting  system  descriptions  that  can  be 
converted  into  iormal  specifications  are  given  in  the  literature.  They  are  a  package  routing 
system  [Swariom  and  Baber  Comm  CACM  25  (1982).  438-440],  a  telephone  dialing  system 
[Dasarathy.  IEEE  Trans. Software  Eng  SL-11  (1985).  80-86],  and  a  furnace  controller 
[from  the  problem  set  in  JT,>c  4th  1  met  national  Workshop  on  Software  Specification  and 
Design .  lr'S~  (  Harandi.  ed. )] 
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granted,  without  fee,  provided  that  the  copies  and  derivative  works  are  not  made  or  distributed  for  direct  commercial 
advantage,  and  that  al  copies  and  derivative  works  cite  the  original  document  by  name,  author's  name,  and  document 
number  and  give  notice  that  the  oopying  is  by  permission  of  Carnegie  Mellon  University. 

Comments  on  SEI  educational  materials  and  requests  for  additional  information  should  be  addressed  to  the  Software 
Engineering  Curriculum  Project,  Software  Engineering  Institute,  Carnegie  Mellon  University,  Pittsburgh,  Pennsylvania 
15213.  Electronic  mail  can  be  sent  to  education@sei.cmu.edu  on  the  Internet. 


Curriculum  Modules  (*  Support  Materials  available) 

CM-1  (superseded  by  CM-19| 

CM-2  Introduction  to  Software  Design 
CM-3  The  Software  Technical  Review  Process* 

CM-4  Software  Configuration  Management* 

CM- 5  Information  Protection 

CM-6  Software  Safety 

CM- 7  Assurance  of  Software  Quaify 

CM4  Formal  Specification  of  Software* 

CM-9  Unit  Testing  and  Analysis 

CM-10  Models  of  Software  Evolution:  Life  Cycle  and  Process 
CM-1 1  Software  Specifications:  A  Framework 
CM- 12  Software  Metrics 

CM- 13  Introduction  to  Software  Verification  and  Validation 
CM- 14  Inlelectuai  Property  Protection  for  Software 
CM- 15  Software  Development  and  Licensing  Contracts 
CM- 16  Software  Development  Using  VDM 
CM- 17  User  Interface  Development* 

CM-1®  (superseded  by  CM-23] 

CM- 19  Software  Requirements 
CM- 20  Formal  Verification  of  Programs 
CM-21  Software  Project  Management 
CM-22  Software  Devgn  Methods  for  Real-Time  Systems* 
CM-23  Technical  Writing  lor  Software  Engineers 
CM- 24  Concepts  of  Concurrent  Programming 
CM- 25  Language  and  System  Support  lor  Concurrent 
Programming* 

CM-26  Understanding  Program  Dependencies 


Educational  Materials 

EM-1  Software  Maintenance  Exercises  for  a  Software 
Engineering  Project  Course 

EM-2  APSE  Interactive  Monitor:  An  Artifact  for  Software 
Engineering  Education 

EM-3  Reading  Computer  Programs:  Instructor's  Guide  and 
Exercises 


